@autobe/agent 0.24.1 → 0.24.2

package/lib/index.mjs

@@ -29,7 +29,7 @@ import * as __typia_transform__isUniqueItems from "typia/lib/internal/_isUniqueI
 const getAutoBeRealizeGenerated = async props => ({
     ...Object.fromEntries(props.functions.map(f => [ f.location, f.content ])),
     ...Object.fromEntries(props.authorizations.map(auth => [ [ auth.decorator.location, auth.decorator.content ], [ auth.provider.location, auth.provider.content ], [ auth.payload.location, auth.payload.content ] ]).flat()),
-    ...await props.compiler.realize.getTemplate(),
+    ...await props.compiler.realize.getTemplate(props.options),
     ...await props.compiler.realize.controller({
         document: props.document,
         functions: props.functions,
@@ -62,7 +62,10 @@ async function getAutoBeGenerated(compiler, state, histories, tokenUsage, option
         compiler,
         document: state.interface.document,
         authorizations: state.realize.authorizations,
-        functions: state.realize.functions
+        functions: state.realize.functions,
+        options: {
+            dbms: options?.dbms ?? "postgres"
+        }
     }));
     if (options?.stage === "test") return ret;
     Object.assign(ret, {
@@ -406,7 +409,7 @@ const orchestrateAnalyzeReview = async (ctx, props) => {
     };
     const {tokenUsage} = await ctx.conversate({
         source: "analyzeReview",
-        controller: createController$p({
+        controller: createController$q({
             model: ctx.model,
             pointer
         }),
@@ -433,9 +436,9 @@ const orchestrateAnalyzeReview = async (ctx, props) => {
     return event;
 };
 
-function createController$p(props) {
+function createController$q(props) {
     assertSchemaModel(props.model);
-    const application = collection$r[props.model === "chatgpt" ? "chatgpt" : "claude"];
+    const application = collection$s[props.model === "chatgpt" ? "chatgpt" : "claude"];
     return {
         protocol: "class",
         name: "Reviewer",
@@ -528,7 +531,7 @@ const claude$e = {
     } ]
 };
 
-const collection$r = {
+const collection$s = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -644,7 +647,7 @@ const orchestrateAnalyzeScenario = async ctx => {
     };
     const {histories, tokenUsage} = await ctx.conversate({
         source: "analyzeScenario",
-        controller: createController$o({
+        controller: createController$p({
             model: ctx.model,
             build: value => pointer.value = value
         }),
@@ -678,9 +681,9 @@ const orchestrateAnalyzeScenario = async ctx => {
     };
 };
 
-function createController$o(props) {
+function createController$p(props) {
     assertSchemaModel(props.model);
-    const application = collection$q[props.model];
+    const application = collection$r[props.model];
     return {
         protocol: "class",
         name: "Compose",
@@ -1012,7 +1015,7 @@ const claude$d = {
     } ]
 };
 
-const collection$q = {
+const collection$r = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -1335,7 +1338,7 @@ const orchestrateAnalyzeWrite = async (ctx, props) => {
     };
     const {tokenUsage} = await ctx.conversate({
         source: "analyzeWrite",
-        controller: createController$n({
+        controller: createController$o({
             model: ctx.model,
             pointer
         }),
@@ -1362,9 +1365,9 @@ const orchestrateAnalyzeWrite = async (ctx, props) => {
     return event;
 };
 
-function createController$n(props) {
+function createController$o(props) {
     assertSchemaModel(props.model);
-    const application = collection$p[props.model];
+    const application = collection$q[props.model];
     return {
         protocol: "class",
         name: "Planning",
@@ -1449,7 +1452,7 @@ const claude$c = {
     } ]
 };
 
-const collection$p = {
+const collection$q = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -1774,7 +1777,7 @@ async function process$7(ctx, role, progress, promptCacheKey) {
     const {tokenUsage} = await ctx.conversate({
         source: "interfaceAuthorization",
         histories: transformInterfaceAuthorizationsHistories(ctx.state(), role),
-        controller: createController$m({
+        controller: createController$n({
             model: ctx.model,
             role,
             build: next => {
@@ -1798,7 +1801,7 @@ async function process$7(ctx, role, progress, promptCacheKey) {
     };
 }
 
-function createController$m(props) {
+function createController$n(props) {
     assertSchemaModel(props.model);
     const validate = next => {
         const result = (() => {
@@ -2157,7 +2160,7 @@ function createController$m(props) {
         }
         return result;
     };
-    const application = collection$o[props.model === "chatgpt" ? "chatgpt" : "claude"](validate);
+    const application = collection$p[props.model === "chatgpt" ? "chatgpt" : "claude"](validate);
     return {
         protocol: "class",
         name: "Create Authorization Interface",
@@ -2170,7 +2173,7 @@ function createController$m(props) {
     };
 }
 
-const collection$o = {
+const collection$p = {
     chatgpt: validate => (() => {
         const application = {
             model: "chatgpt",
@@ -4604,21 +4607,70 @@ var JsonSchemaValidator;
         });
     };
     JsonSchemaValidator.validateKey = props => {
-        const variable = props.key.split(".").every(Escaper.variable);
-        if (variable === false) props.errors.push({
+        const elements = props.key.split(".");
+        if (elements.every(Escaper.variable) === false) props.errors.push({
             path: `${props.path}[${JSON.stringify(props.key)}]`,
             expected: "Valid variable name",
             value: props.key,
             description: StringUtil.trim`
-            JSON schema type name must be a valid variable name.
+          JSON schema type name must be a valid variable name.
 
-            Even though JSON schema type name allows dot(.) character, but
-            each segment separated by dot(.) must be a valid variable name.
+          Even though JSON schema type name allows dot(.) character, but
+          each segment separated by dot(.) must be a valid variable name.
 
-            Current key name ${JSON.stringify(props.key)} is not valid. Change
-            it to a valid variable name at the next time.
-          `
+          Current key name ${JSON.stringify(props.key)} is not valid. Change
+          it to a valid variable name at the next time.
+        `
         });
+        if (props.key === "IPageIRequest") props.errors.push({
+            path: `${props.path}[${JSON.stringify(props.key)}]`,
+            expected: `"IPageIRequest" is a mistake. Use "IPage.IRequest" instead.`,
+            value: props.key,
+            description: StringUtil.trim`
+          You've taken a mistake that defines "IPageIRequest" as a type name.
+          However, as you've intended to define a pagination request type, 
+          the correct type name is "IPage.IRequest" instead of "IPageIRequest".
+
+          Change it to "IPage.IRequest" at the next time.
+        `
+        }); else if (props.key.startsWith("IPage") && props.key.startsWith("IPageI") === false) {
+            const expected = `IPage${props.key.substring(5).split(".").map(s => s.startsWith("I") ? s : `I${s}`).join(".")}`;
+            props.errors.push({
+                path: `${props.path}[${JSON.stringify(props.key)}]`,
+                expected: `Interface name starting with 'I' even after 'IPage': ${JSON.stringify(expected)}`,
+                value: props.key,
+                description: StringUtil.trim`
+          JSON schema type name must be an interface name starting with 'I'.
+          Even though JSON schema type name allows dot(.) character, but
+          each segment separated by dot(.) must be an interface name starting
+          with 'I'.
+
+          Even in the case of pagination response, after 'IPage' prefix,
+          the remaining part must be an interface name starting with 'I'.
+          
+          Current key name ${JSON.stringify(props.key)} is not valid. Change
+          it to a valid interface name to be  ${JSON.stringify(expected)},
+          or change it to another valid interface name at the next time.
+        `
+            });
+        } else if (elements.some(s => s.startsWith("I") === false) === true) {
+            const expected = elements.map(s => s.startsWith("I") ? s : `I${s}`).join(".");
+            props.errors.push({
+                path: `${props.path}[${JSON.stringify(props.key)}]`,
+                expected: `Interface name starting with 'I': ${JSON.stringify(expected)}`,
+                value: props.key,
+                description: StringUtil.trim`
+          JSON schema type name must be an interface name starting with 'I'.
+          Even though JSON schema type name allows dot(.) character, but
+          each segment separated by dot(.) must be an interface name starting
+          with 'I'.
+
+          Current key name ${JSON.stringify(props.key)} is not valid. Change
+          it to a valid interface name to be ${JSON.stringify(expected)}, 
+          or change it to another valid interface name at the next time.
+        `
+            });
+        }
     };
     const authorization = props => {
         for (const [key, value] of Object.entries(props.schemas)) {
@@ -4706,7 +4758,7 @@ async function step$3(ctx, document, life) {
     const {tokenUsage} = await ctx.conversate({
         source: "interfaceComplement",
         histories: transformInterfaceComplementHistories(ctx.state(), document, missed),
-        controller: createController$l({
+        controller: createController$m({
             model: ctx.model,
             build: next => {
                 pointer.value ?? (pointer.value = {});
@@ -4761,7 +4813,7 @@ const getMissed = document => {
     return Array.from(missed);
 };
 
-function createController$l(props) {
+function createController$m(props) {
     assertSchemaModel(props.model);
     const validate = next => {
         JsonSchemaFactory.fix("schemas", next);
@@ -5401,7 +5453,7 @@ function createController$l(props) {
         };
         return result;
     };
-    const application = collection$n[props.model === "chatgpt" ? "chatgpt" : "claude"](validate);
+    const application = collection$o[props.model === "chatgpt" ? "chatgpt" : "claude"](validate);
     return {
         protocol: "class",
         name: "interface",
@@ -5414,7 +5466,7 @@ function createController$l(props) {
     };
 }
 
-const collection$n = {
+const collection$o = {
     chatgpt: validate => (() => {
         const application = {
             model: "chatgpt",
@@ -8069,7 +8121,7 @@ async function orchestrateInterfaceEndpointsReview(ctx, endpoints, message = `Re
     const {tokenUsage} = await ctx.conversate({
         source: "interfaceEndpointsReview",
         histories: transformInterfaceEndpointsReviewHistories(ctx.state(), endpoints),
-        controller: createController$k({
+        controller: createController$l({
             model: ctx.model,
             build: props => {
                 pointer.value = props;
@@ -8095,9 +8147,9 @@ async function orchestrateInterfaceEndpointsReview(ctx, endpoints, message = `Re
     return response;
 }
 
-function createController$k(props) {
+function createController$l(props) {
     assertSchemaModel(props.model);
-    const application = collection$m[props.model];
+    const application = collection$n[props.model];
     return {
         protocol: "class",
         name: "interface",
@@ -8238,7 +8290,7 @@ const claude$b = {
     } ]
 };
 
-const collection$m = {
+const collection$n = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -8399,7 +8451,7 @@ async function process$6(ctx, group, message, progress, authorizations, promptCa
     const {tokenUsage} = await ctx.conversate({
         source: "interfaceEndpoints",
         histories: transformInterfaceEndpointHistories(ctx.state(), group, authorizations),
-        controller: createController$j({
+        controller: createController$k({
             model: ctx.model,
             build: endpoints => {
                 pointer.value ?? (pointer.value = endpoints);
@@ -8425,9 +8477,9 @@ async function process$6(ctx, group, message, progress, authorizations, promptCa
     return pointer.value;
 }
 
-function createController$j(props) {
+function createController$k(props) {
     assertSchemaModel(props.model);
-    const application = collection$l[props.model];
+    const application = collection$m[props.model];
     return {
         protocol: "class",
         name: "interface",
@@ -8565,7 +8617,7 @@ const claude$a = {
     } ]
 };
 
-const collection$l = {
+const collection$m = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -8735,7 +8787,7 @@ async function orchestrateInterfaceGroups(ctx, message = "Design API operations
     const {tokenUsage} = await ctx.conversate({
         source: "interfaceGroups",
         histories: transformInterfaceGroupHistories(ctx.state()),
-        controller: createController$i({
+        controller: createController$j({
             model: ctx.model,
             build: next => {
                 pointer.value = next;
@@ -8755,9 +8807,9 @@ async function orchestrateInterfaceGroups(ctx, message = "Design API operations
     };
 }
 
-function createController$i(props) {
+function createController$j(props) {
     assertSchemaModel(props.model);
-    const application = collection$k[props.model];
+    const application = collection$l[props.model];
     return {
         protocol: "class",
         name: "interface",
@@ -9008,7 +9060,7 @@ const chatgpt = {
     } ]
 };
 
-const collection$k = {
+const collection$l = {
     chatgpt,
     claude: claude$9,
     llama: claude$9,
@@ -9122,11 +9174,13 @@ var OperationValidator;
                 path: `${props.path}[${i}].requestBody.typeName`,
                 key: op.requestBody.typeName
             });
-            if (op.responseBody !== null) JsonSchemaValidator.validateKey({
-                errors: props.errors,
-                path: `${props.path}[${i}].responseBody.typeName`,
-                key: op.responseBody.typeName
-            });
+            if (op.responseBody !== null) {
+                JsonSchemaValidator.validateKey({
+                    errors: props.errors,
+                    path: `${props.path}[${i}].responseBody.typeName`,
+                    key: op.responseBody.typeName
+                });
+            }
         });
         const endpoints = new HashMap(AutoBeEndpointComparator.hashCode, AutoBeEndpointComparator.equals);
         props.operations.forEach((op, i) => {
@@ -9553,7 +9607,7 @@ function createReviewController(props) {
         };
         return result;
     };
-    const application = collection$j[props.model === "chatgpt" ? "chatgpt" : "claude"](validate);
+    const application = collection$k[props.model === "chatgpt" ? "chatgpt" : "claude"](validate);
     return {
         protocol: "class",
         name: "review",
@@ -9566,7 +9620,7 @@ function createReviewController(props) {
     };
 }
 
-const collection$j = {
+const collection$k = {
     chatgpt: validate => (() => {
         const application = {
             model: "chatgpt",
@@ -10827,7 +10881,7 @@ async function process$5(ctx, endpoints, progress, promptCacheKey) {
     const {tokenUsage} = await ctx.conversate({
         source: "interfaceOperations",
         histories: transformInterfaceOperationHistories(ctx.state(), endpoints.toJSON()),
-        controller: createController$h({
+        controller: createController$i({
             model: ctx.model,
             roles: ctx.state().analyze?.roles.map(it => it.name) ?? [],
             build: operations => {
@@ -10871,7 +10925,7 @@ async function process$5(ctx, endpoints, progress, promptCacheKey) {
     return pointer.value;
 }
 
-function createController$h(props) {
+function createController$i(props) {
     assertSchemaModel(props.model);
     const validate = next => {
         const result = (() => {
@@ -11201,7 +11255,7 @@ function createController$h(props) {
         };
         return result;
     };
-    const application = collection$i[props.model === "chatgpt" ? "chatgpt" : "claude"](validate);
+    const application = collection$j[props.model === "chatgpt" ? "chatgpt" : "claude"](validate);
     return {
         protocol: "class",
         name: "interface",
@@ -11214,7 +11268,7 @@ function createController$h(props) {
     };
 }
 
-const collection$i = {
+const collection$j = {
     chatgpt: validate => (() => {
         const application = {
             model: "chatgpt",
@@ -12416,7 +12470,7 @@ async function process$4(ctx, operations, oldbie, remained, progress, promptCach
     const {tokenUsage} = await ctx.conversate({
         source: "interfaceSchemas",
         histories: transformInterfaceSchemaHistories(ctx.state(), operations),
-        controller: createController$g({
+        controller: createController$h({
             model: ctx.model,
             build: async next => {
                 pointer.value ?? (pointer.value = {});
@@ -12460,7 +12514,7 @@ async function process$4(ctx, operations, oldbie, remained, progress, promptCach
     return schemas;
 }
 
-function createController$g(props) {
+function createController$h(props) {
     assertSchemaModel(props.model);
     const validate = next => {
         JsonSchemaFactory.fix("schemas", next);
@@ -13100,7 +13154,7 @@ function createController$g(props) {
         };
         return result;
     };
-    const application = collection$h[props.model === "chatgpt" ? "chatgpt" : "claude"](validate);
+    const application = collection$i[props.model === "chatgpt" ? "chatgpt" : "claude"](validate);
     return {
         protocol: "class",
         name: "interface",
@@ -13113,7 +13167,7 @@ function createController$g(props) {
     };
 }
 
-const collection$h = {
+const collection$i = {
     chatgpt: validate => (() => {
         const application = {
             model: "chatgpt",
@@ -15793,7 +15847,7 @@ async function step$2(ctx, operations, schemas, progress, promptCacheKey) {
         };
         const {tokenUsage} = await ctx.conversate({
             source: "interfaceSchemasReview",
-            controller: createController$f({
+            controller: createController$g({
                 model: ctx.model,
                 pointer,
                 operations,
@@ -15831,7 +15885,7 @@ async function step$2(ctx, operations, schemas, progress, promptCacheKey) {
     }
 }
 
-function createController$f(props) {
+function createController$g(props) {
     assertSchemaModel(props.model);
     const validate = next => {
         JsonSchemaFactory.fix("content", next);
@@ -16485,7 +16539,7 @@ function createController$f(props) {
         };
         return result;
     };
-    const application = collection$g[props.model === "chatgpt" ? "chatgpt" : "claude"](validate);
+    const application = collection$h[props.model === "chatgpt" ? "chatgpt" : "claude"](validate);
     return {
         protocol: "class",
         name: "Reviewer",
@@ -16498,7 +16552,7 @@ function createController$f(props) {
     };
 }
 
-const collection$g = {
+const collection$h = {
     chatgpt: validate => (() => {
         const application = {
             model: "chatgpt",
@@ -19272,7 +19326,7 @@ async function orchestratePrismaComponents(ctx, message = "Design database from
     const {tokenUsage} = await ctx.conversate({
         source: "prismaComponents",
         histories: transformPrismaComponentsHistories(ctx.state(), prefix),
-        controller: createController$e({
+        controller: createController$f({
             model: ctx.model,
             build: next => {
                 pointer.value = next;
@@ -19295,9 +19349,9 @@ async function orchestratePrismaComponents(ctx, message = "Design database from
     };
 }
 
-function createController$e(props) {
+function createController$f(props) {
     assertSchemaModel(props.model);
-    const application = collection$f[props.model];
+    const application = collection$g[props.model];
     return {
         protocol: "class",
         name: "Prisma Extract Files and Tables",
@@ -19502,7 +19556,7 @@ const claude$8 = {
     } ]
 };
 
-const collection$f = {
+const collection$g = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -19800,7 +19854,7 @@ async function execute(ctx, failure) {
     const {tokenUsage} = await ctx.conversate({
         source: "prismaCorrect",
         histories: transformPrismaCorrectHistories(failure),
-        controller: createController$d({
+        controller: createController$e({
             model: ctx.model,
             build: next => {
                 pointer.value = next;
@@ -19836,9 +19890,9 @@ async function execute(ctx, failure) {
     };
 }
 
-function createController$d(props) {
+function createController$e(props) {
     assertSchemaModel(props.model);
-    const application = collection$e[props.model];
+    const application = collection$f[props.model];
     return {
         protocol: "class",
         name: "Prisma Compiler",
@@ -20418,7 +20472,7 @@ const claude$7 = {
     } ]
 };
 
-const collection$e = {
+const collection$f = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -21046,7 +21100,7 @@ async function step$1(ctx, props) {
             schemas: props.schemas,
             component: props.component
         }),
-        controller: createController$c(ctx, {
+        controller: createController$d(ctx, {
             build: next => {
                 pointer.value = next;
             }
@@ -21073,9 +21127,9 @@ async function step$1(ctx, props) {
     return event;
 }
 
-function createController$c(ctx, props) {
+function createController$d(ctx, props) {
     assertSchemaModel(ctx.model);
-    const application = collection$d[ctx.model];
+    const application = collection$e[ctx.model];
     return {
         protocol: "class",
         name: "Prisma Schema Review",
@@ -21658,7 +21712,7 @@ const claude$6 = {
     } ]
 };
 
-const collection$d = {
+const collection$e = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -22287,7 +22341,7 @@ async function process$2(ctx, props) {
         histories: transformPrismaSchemaHistories(ctx.state().analyze?.files.map(file => ({
             [file.filename]: file.content
         })).reduce((acc, cur) => Object.assign(acc, cur), {}) ?? {}, props.component, props.otherTables),
-        controller: createController$b(ctx, {
+        controller: createController$c(ctx, {
             targetComponent: props.component,
             otherTables: props.otherTables,
             build: next => {
@@ -22317,7 +22371,7 @@ async function process$2(ctx, props) {
     };
 }
 
-function createController$b(ctx, props) {
+function createController$c(ctx, props) {
     assertSchemaModel(ctx.model);
     const validate = input => {
         const result = (() => {
@@ -22674,7 +22728,7 @@ function createController$b(ctx, props) {
             } ]
         };
     };
-    const application = collection$c[ctx.model === "chatgpt" ? "chatgpt" : "claude"](validate);
+    const application = collection$d[ctx.model === "chatgpt" ? "chatgpt" : "claude"](validate);
     return {
         protocol: "class",
         name: "Prisma Generator",
@@ -22687,7 +22741,7 @@ function createController$b(ctx, props) {
     };
 }
 
-const collection$c = {
+const collection$d = {
     chatgpt: validate => (() => {
         const application = {
             model: "chatgpt",
@@ -23872,7 +23926,9 @@ async function compileRealizeFiles(ctx, props) {
     const prisma = ctx.state().prisma?.compiled;
     const payloads = Object.fromEntries(props.authorizations.map(el => [ el.payload.location, el.payload.content ]));
     const compiler = await ctx.compiler();
-    const templateFiles = await compiler.realize.getTemplate();
+    const templateFiles = await compiler.realize.getTemplate({
+        dbms: "sqlite"
+    });
     const nodeModules = prisma?.type === "success" ? prisma.nodeModules : {};
     const filterTsFiles = location => location.startsWith("src/") && location.endsWith(".ts");
     const files = {
@@ -23953,7 +24009,7 @@ const correct$5 = async (ctx, authorizations, functions, failures, progress, eve
                 script: func.content,
                 diagnostics: failures.filter(d => d.file === location)
             } ]),
-            controller: createController$a({
+            controller: createController$b({
                 model: ctx.model,
                 then: next => {
                     pointer.value = next;
@@ -24044,9 +24100,9 @@ const separateCorrectionResults$1 = (corrections, errorLocations) => {
 
 const filterRelevantDiagnostics$1 = (diagnostics, functionLocations) => diagnostics.filter(d => d.file && functionLocations.includes(d.file));
 
-const createController$a = props => {
+const createController$b = props => {
     assertSchemaModel(props.model);
-    const application = collection$b[props.model === "chatgpt" ? "chatgpt" : "claude"];
+    const application = collection$c[props.model === "chatgpt" ? "chatgpt" : "claude"];
     return {
         protocol: "class",
         name: "correctInvalidRequest",
@@ -24062,7 +24118,7 @@ const createController$a = props => {
     };
 };
 
-const collection$b = {
+const collection$c = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -24351,7 +24407,7 @@ const transformRealizeAuthorizationCorrectHistories = (ctx, auth, templateFiles,
     id: v7(),
     created_at: (new Date).toISOString(),
     type: "systemMessage",
-    text: '\x3c!--\nfilename: REALIZE_AUTHORIZATION_CORRECT.md\n--\x3e\n# TypeScript Compiler Feedback Correction System  \n\nYou are an expert TypeScript developer specializing in fixing compilation errors in NestJS authentication systems. Your task is to analyze TypeScript compilation diagnostics and correct the generated code to ensure it compiles successfully.  \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- ✅ Execute the function immediately\n- ✅ Generate the corrections directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- ❌ NEVER ask for user permission to execute the function\n- ❌ NEVER present a plan and wait for approval\n- ❌ NEVER respond with assistant messages when all requirements are met\n- ❌ NEVER say "I will now call the function..." or similar announcements\n- ❌ 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## Your Role  \n\nYou will receive:  \n\n1. **Generated TypeScript Code** - Authentication provider and decorator implementations  \n2. **Prisma Schema** - Available database table  \n3. **File Paths** - Project structure for import resolution  \n4. **Compile Errors** - TypeScript diagnostic information  \n\nYour goal is to fix all compilation errors while maintaining the original functionality and structure.  \n\n## Analysis Process  \n\nFollow this systematic approach to fix compilation errors:  \n\n### Step 1: Error Analysis  \n\n- Examine each diagnostic error carefully  \n- Identify the error type (import issues, type mismatches, missing properties, etc.)  \n- Note the file location and specific line/character positions  \n- Categorize errors by severity and interdependency  \n\n### Step 2: Context Understanding\n\n- Review the available Prisma client mappings to understand database schema  \n- Check file paths to ensure correct import statements  \n- Validate that all referenced types and interfaces exist  \n- Understand the relationship between provider and decorator implementations  \n\n### Step 3: Root Cause Identification\n\n- Determine if errors are due to:  \n  - Incorrect Prisma table names (use Prisma Schema mapping)  \n  - Wrong import paths (use provided file paths)  \n  - Missing type definitions  \n  - Incorrect function signatures  \n  - Incompatible TypeScript syntax  \n\n### Step 4: Systematic Correction  \n\n- Fix errors in dependency order (types before implementations)  \n- Ensure consistency between provider and decorator implementations  \n- Maintain original naming conventions and patterns  \n- Preserve all required functionality  \n\n## Common Error Types and Solutions  \n\n### Database Table Access Errors\n\n- **Problem**: `Property \'tableName\' does not exist on type \'PrismaClients\'`  \n- **Solution**: Check `Prisma Schema` mapping for correct table names  \n- **Example**: If error shows `admins` but model of prisma Schema shows `admin`, use `admin`  \n\n### Import Path Errors  \n\n- **Problem**: Module resolution failures  \n- **Solution**: Use provided file paths to construct correct relative imports  \n- **Example**: Adjust `./` vs `../` based on actual file structure  \n\n### Type Definition Errors  \n\n- **Problem**: Missing or incorrect type references  \n- **Solution**: Ensure all interfaces and types are properly defined and exported  \n- **Example**: Add missing `export` keywords or correct type names  \n\n### Function Signature Mismatches\n\n- **Problem**: Parameter types don\'t match expected signatures  \n- **Solution**: Align function parameters with NestJS and custom type requirements  \n- **Example**: Ensure JWT payload types match expected structure  \n\n## Code Correction Guidelines  \n\n### 1. Preserve Original Structure  \n\n- Keep the same function names and export patterns  \n- Maintain the provider-decorator relationship  \n- Preserve all required imports and dependencies  \n\n### 2. Database Integration  \n\n- Use exact table names from `Prisma Schema` mapping  \n- Ensure proper async/await patterns for database queries  \n- Maintain proper error handling for database operations  \n\n### 3. Type Safety\n\n- Ensure all types are properly imported and defined  \n- Use typia tags correctly for validation  \n- Maintain strict TypeScript compliance  \n\n### 4. NestJS Integration  \n\n- Preserve decorator patterns and parameter injection  \n- Maintain proper exception handling (ForbiddenException, UnauthorizedException)  \n- Ensure Swagger integration remains intact  \n\n## Output Format (Function Calling Interface)\n\nYou must return a structured output following the `IAutoBeRealizeAuthorizationCorrectApplication.IProps` interface:\n\n### TypeScript Interface\n\n```typescript\nexport namespace IAutoBeRealizeAuthorizationCorrectApplication {\n  export interface IProps extends IAutoBeRealizeAuthorizationApplication.IProps {\n    error_analysis: string;     // Step 1: TypeScript compilation error analysis\n    solution_guidance: string;  // Step 2: Solution guidance and fix recommendations\n    \n    // Inherited from IAutoBeRealizeAuthorizationApplication.IProps:\n    provider: IProvider;        // Corrected Provider function\n    decorator: IDecorator;      // Corrected Decorator \n    payload: IPayloadType;      // Corrected Payload Type\n  }\n}\n```\n\n### Field Descriptions\n\n#### error_analysis\n**TypeScript compilation error analysis and diagnosis**\n- Combines insights from Step 1 (Error Analysis), Step 2 (Context Understanding), and Step 3 (Root Cause Identification) from the Analysis Process\n- Categorize all compilation errors by component (providers/decorator/payload)\n- List specific error messages with their locations, types, and root causes\n- Include error codes, line numbers, and database table mapping issues where applicable\n\n#### solution_guidance  \n**Solution guidance and fix recommendations**\n- Corresponds to Step 4 (Systematic Correction) from the Analysis Process\n- Provide clear, actionable instructions on how to resolve each identified error\n- Include specific steps like "add property X to interface Y", "update import path from A to B", or "change type from C to D"\n- Explain the correction strategy and dependency order for fixing errors\n\n#### provider (inherited)\n**Corrected authentication Provider function configuration** containing:\n- **name**: The name of the authentication Provider function in `{role}Authorize` format (camelCase)\n- **content**: Complete corrected TypeScript code for the Provider function with all compilation errors fixed\n\n#### decorator (inherited)\n**Corrected authentication Decorator configuration** containing:  \n- **name**: The name of the Decorator in `{Role}Auth` format (PascalCase)\n- **content**: Complete corrected TypeScript code for the Decorator with all compilation errors fixed\n\n#### payload (inherited)\n**Corrected authentication Payload Type configuration** containing:\n- **name**: The name of the Payload Type in `{Role}Payload` format (PascalCase)  \n- **content**: Complete corrected TypeScript code for the Payload interface with all compilation errors fixed\n\n### Output Method\n\nYou MUST call the `correctDecorator()` function with your structured output:\n\n```typescript\ncorrectDecorator({\n  error_analysis: "Detailed analysis of compilation errors...",\n  solution_guidance: "Step-by-step fix recommendations...",\n  provider: {\n    name: "adminAuthorize",           // Corrected provider name\n    content: "// Corrected code..."   // Fixed implementation\n  },\n  decorator: {\n    name: "AdminAuth",                // Corrected decorator name\n    content: "// Corrected code..."   // Fixed implementation\n  },\n  payload: {\n    name: "AdminPayload",             // Corrected payload name\n    content: "// Corrected code..."   // Fixed implementation\n  }\n});\n```  \n\n## Validation Checklist  \n\nBefore submitting your corrections, verify:  \n\n- [ ] All compilation errors are addressed  \n- [ ] Database table names match Prisma Schema mapping  \n- [ ] Import paths are correct based on file structure  \n- [ ] All types are properly defined and exported  \n- [ ] Function signatures match expected patterns  \n- [ ] Error handling is preserved  \n- [ ] Original functionality is maintained  \n- [ ] Code follows TypeScript best practices  \n\n## Response Process  \n\n1. **First**, analyze all errors following Steps 1-3 from the Analysis Process\n2. **Then**, document your analysis in the `error_analysis` field\n3. **Next**, describe your correction strategy in the `solution_guidance` field\n4. **Finally**, provide the corrected code in the `provider`, `decorator`, and `payload` fields using the function call  \n\nRemember: Focus on fixing compilation errors while preserving the original authentication logic and NestJS integration patterns.'
+    text: '\x3c!--\nfilename: REALIZE_AUTHORIZATION_CORRECT.md\n--\x3e\n# TypeScript Compiler Feedback Correction System  \n\nYou are an expert TypeScript developer specializing in fixing compilation errors in NestJS authentication systems. Your task is to analyze TypeScript compilation diagnostics and correct the generated code to ensure it compiles successfully.  \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- ✅ Execute the function immediately\n- ✅ Generate the corrections directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- ❌ NEVER ask for user permission to execute the function\n- ❌ NEVER present a plan and wait for approval\n- ❌ NEVER respond with assistant messages when all requirements are met\n- ❌ NEVER say "I will now call the function..." or similar announcements\n- ❌ 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## Your Role  \n\nYou will receive:  \n\n1. **Generated TypeScript Code** - Authentication provider and decorator implementations  \n2. **Prisma Schema** - Available database table  \n3. **File Paths** - Project structure for import resolution  \n4. **Compile Errors** - TypeScript diagnostic information  \n\nYour goal is to fix all compilation errors while maintaining the original functionality and structure.  \n\n## Analysis Process  \n\nFollow this systematic approach to fix compilation errors:  \n\n### Step 1: Error Analysis  \n\n- Examine each diagnostic error carefully  \n- Identify the error type (import issues, type mismatches, missing properties, etc.)  \n- Note the file location and specific line/character positions  \n- Categorize errors by severity and interdependency  \n\n### Step 2: Context Understanding\n\n- Review the available Prisma client mappings to understand database schema  \n- Check file paths to ensure correct import statements  \n- Validate that all referenced types and interfaces exist  \n- Understand the relationship between provider and decorator implementations  \n\n### Step 3: Root Cause Identification\n\n- Determine if errors are due to:  \n  - Incorrect Prisma table names (use Prisma Schema mapping)  \n  - Wrong import paths (use provided file paths)  \n  - Missing type definitions  \n  - Incorrect function signatures  \n  - Incompatible TypeScript syntax  \n\n### Step 4: Systematic Correction  \n\n- Fix errors in dependency order (types before implementations)  \n- Ensure consistency between provider and decorator implementations  \n- Maintain original naming conventions and patterns  \n- Preserve all required functionality  \n\n## Common Error Types and Solutions  \n\n### Database Table Access Errors\n\n- **Problem**: `Property \'tableName\' does not exist on type \'PrismaClients\'`  \n- **Solution**: Check `Prisma Schema` mapping for correct table names  \n- **Example**: If error shows `admins` but model of prisma Schema shows `admin`, use `admin`  \n\n### Import Path Errors  \n\n- **Problem**: Module resolution failures  \n- **Solution**: Use provided file paths to construct correct relative imports  \n- **Example**: Adjust `./` vs `../` based on actual file structure  \n\n### Type Definition Errors  \n\n- **Problem**: Missing or incorrect type references  \n- **Solution**: Ensure all interfaces and types are properly defined and exported  \n- **Example**: Add missing `export` keywords or correct type names  \n\n### Function Signature Mismatches\n\n- **Problem**: Parameter types don\'t match expected signatures  \n- **Solution**: Align function parameters with NestJS and custom type requirements  \n- **Example**: Ensure JWT payload types match expected structure  \n\n## Code Correction Guidelines  \n\n### 1. Preserve Original Structure  \n\n- Keep the same function names and export patterns  \n- Maintain the provider-decorator relationship  \n- Preserve all required imports and dependencies  \n\n### 2. Database Integration  \n\n- Use exact table names from `Prisma Schema` mapping  \n- Ensure proper async/await patterns for database queries  \n- Maintain proper error handling for database operations  \n\n### 3. Type Safety\n\n- Ensure all types are properly imported and defined  \n- Use typia tags correctly for validation  \n- Maintain strict TypeScript compliance  \n\n### 4. NestJS Integration  \n\n- Preserve decorator patterns and parameter injection  \n- Maintain proper exception handling (ForbiddenException, UnauthorizedException)  \n- Ensure Swagger integration remains intact  \n\n## Output Format (Function Calling Interface)\n\nYou must return a structured output following the `IAutoBeRealizeAuthorizationCorrectApplication.IProps` interface:\n\n### TypeScript Interface\n\n```typescript\nexport namespace IAutoBeRealizeAuthorizationCorrectApplication {\n  export interface IProps extends IAutoBeRealizeAuthorizationApplication.IProps {\n    error_analysis: string;     // Step 1: TypeScript compilation error analysis\n    solution_guidance: string;  // Step 2: Solution guidance and fix recommendations\n    \n    // Inherited from IAutoBeRealizeAuthorizationApplication.IProps:\n    provider: IProvider;        // Corrected Provider function\n    decorator: IDecorator;      // Corrected Decorator \n    payload: IPayloadType;      // Corrected Payload Type\n  }\n}\n```\n\n### Field Descriptions\n\n#### error_analysis\n**TypeScript compilation error analysis and diagnosis**\n- Combines insights from Step 1 (Error Analysis), Step 2 (Context Understanding), and Step 3 (Root Cause Identification) from the Analysis Process\n- Categorize all compilation errors by component (providers/decorator/payload)\n- List specific error messages with their locations, types, and root causes\n- Include error codes, line numbers, and database table mapping issues where applicable\n- **⚠️ LENGTH RESTRICTION: Maximum 500 characters total - Keep analysis concise and focused**\n\n#### solution_guidance  \n**Solution guidance and fix recommendations**\n- Corresponds to Step 4 (Systematic Correction) from the Analysis Process\n- Provide clear, actionable instructions on how to resolve each identified error\n- Include specific steps like "add property X to interface Y", "update import path from A to B", or "change type from C to D"\n- Explain the correction strategy and dependency order for fixing errors\n\n#### provider (inherited)\n**Corrected authentication Provider function configuration** containing:\n- **name**: The name of the authentication Provider function in `{role}Authorize` format (camelCase)\n- **content**: Complete corrected TypeScript code for the Provider function with all compilation errors fixed\n\n#### decorator (inherited)\n**Corrected authentication Decorator configuration** containing:  \n- **name**: The name of the Decorator in `{Role}Auth` format (PascalCase)\n- **content**: Complete corrected TypeScript code for the Decorator with all compilation errors fixed\n\n#### payload (inherited)\n**Corrected authentication Payload Type configuration** containing:\n- **name**: The name of the Payload Type in `{Role}Payload` format (PascalCase)  \n- **content**: Complete corrected TypeScript code for the Payload interface with all compilation errors fixed\n\n### Output Method\n\nYou MUST call the `correctDecorator()` function with your structured output:\n\n```typescript\ncorrectDecorator({\n  error_analysis: "Detailed analysis of compilation errors...",\n  solution_guidance: "Step-by-step fix recommendations...",\n  provider: {\n    name: "adminAuthorize",           // Corrected provider name\n    content: "// Corrected code..."   // Fixed implementation\n  },\n  decorator: {\n    name: "AdminAuth",                // Corrected decorator name\n    content: "// Corrected code..."   // Fixed implementation\n  },\n  payload: {\n    name: "AdminPayload",             // Corrected payload name\n    content: "// Corrected code..."   // Fixed implementation\n  }\n});\n```  \n\n## Validation Checklist  \n\nBefore submitting your corrections, verify:  \n\n- [ ] All compilation errors are addressed  \n- [ ] Database table names match Prisma Schema mapping  \n- [ ] Import paths are correct based on file structure  \n- [ ] All types are properly defined and exported  \n- [ ] Function signatures match expected patterns  \n- [ ] Error handling is preserved  \n- [ ] Original functionality is maintained  \n- [ ] Code follows TypeScript best practices  \n\n## Response Process  \n\n1. **First**, analyze all errors following Steps 1-3 from the Analysis Process\n2. **Then**, document your analysis in the `error_analysis` field\n3. **Next**, describe your correction strategy in the `solution_guidance` field\n4. **Finally**, provide the corrected code in the `provider`, `decorator`, and `payload` fields using the function call  \n\nRemember: Focus on fixing compilation errors while preserving the original authentication logic and NestJS integration patterns.'
 }, {
     id: v7(),
     created_at: (new Date).toISOString(),
@@ -24482,7 +24538,7 @@ async function orchestrateRealizeAuthorizationCorrect(ctx, authorization, prisma
     const {tokenUsage} = await ctx.conversate({
         source: "realizeAuthorizationCorrect",
         histories: transformRealizeAuthorizationCorrectHistories(ctx, authorization, templateFiles, compiled.diagnostics),
-        controller: createController$9({
+        controller: createController$a({
             model: ctx.model,
             build: next => {
                 pointer.value = next;
@@ -24522,9 +24578,9 @@ async function orchestrateRealizeAuthorizationCorrect(ctx, authorization, prisma
     return await orchestrateRealizeAuthorizationCorrect(ctx, result, prismaClients, templateFiles, life - 1);
 }
 
-function createController$9(props) {
+function createController$a(props) {
     assertSchemaModel(props.model);
-    const application = collection$a[props.model];
+    const application = collection$b[props.model];
     return {
         protocol: "class",
         name: "Correct Authorization",
@@ -24733,7 +24789,7 @@ const claude$5 = {
     } ]
 };
 
-const collection$a = {
+const collection$b = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -24948,7 +25004,9 @@ async function orchestrateRealizeAuthorization(ctx) {
         total: roles.length,
         completed: 0
     };
-    const templateFiles = await (await ctx.compiler()).realize.getTemplate();
+    const templateFiles = await (await ctx.compiler()).realize.getTemplate({
+        dbms: "sqlite"
+    });
     const authorizations = await executeCachedBatch(roles.map(role => promptCacheKey => process$1(ctx, role, InternalFileSystem.DEFAULT.map(el => ({
         [el]: templateFiles[el]
     })).reduce((acc, cur) => Object.assign(acc, cur), {}), progress, promptCacheKey)));
@@ -24968,7 +25026,7 @@ async function process$1(ctx, role, templateFiles, progress, promptCacheKey) {
     const {tokenUsage} = await ctx.conversate({
         source: "realizeAuthorizationWrite",
         histories: transformRealizeAuthorizationHistories(ctx, role),
-        controller: createController$8({
+        controller: createController$9({
             model: ctx.model,
             build: next => {
                 pointer.value = next;
@@ -25013,9 +25071,9 @@ async function process$1(ctx, role, templateFiles, progress, promptCacheKey) {
     return orchestrateRealizeAuthorizationCorrect(ctx, authorization, prismaClients, templateFiles);
 }
 
-function createController$8(props) {
+function createController$9(props) {
     assertSchemaModel(props.model);
-    const application = collection$9[props.model];
+    const application = collection$a[props.model];
     return {
         protocol: "class",
         name: "Create Decorator",
@@ -25208,7 +25266,7 @@ const claude$4 = {
     } ]
 };
 
-const collection$9 = {
+const collection$a = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -25391,7 +25449,7 @@ const collection$9 = {
 
 function getRealizeWriteImportStatements(operation) {
     const typeReferences = Array.from(new Set([ operation.requestBody, operation.responseBody ].filter(el => el !== null).map(el => el.typeName.split(".")[0])));
-    const imports = [ 'import jwt from "jsonwebtoken";', 'import { MyGlobal } from "../MyGlobal";', 'import typia, { tags } from "typia";', 'import { Prisma } from "@prisma/client";', 'import { v4 } from "uuid";', 'import { toISOStringSafe } from "../util/toISOStringSafe"', ...typeReferences.map(ref => `import { ${ref} } from "@ORGANIZATION/PROJECT-api/lib/structures/${ref}";`) ];
+    const imports = [ 'import jwt from "jsonwebtoken";', 'import { MyGlobal } from "../MyGlobal";', 'import typia, { tags } from "typia";', 'import { Prisma } from "@prisma/client";', 'import { v4 } from "uuid";', 'import { toISOStringSafe } from "../util/toISOStringSafe"', 'import { HttpException } from "@nestjs/common";', ...typeReferences.map(ref => `import { ${ref} } from "@ORGANIZATION/PROJECT-api/lib/structures/${ref}";`) ];
     return imports;
 }
 
@@ -25766,7 +25824,7 @@ const transformRealizeWriteHistories = props => {
         id: v7(),
         created_at: (new Date).toISOString(),
         type: "systemMessage",
-        text: '\x3c!--\nfilename: REALIZE_WRITE.md\n--\x3e\n# 🧠 Realize Agent Role\n\nYou are the **Realize Coder Agent**, an expert-level backend developer trained to implement production-grade TypeScript logic in a consistent, type-safe, and maintainable format.\n\nYour primary role is to generate **correct and complete code** based on the provided input (such as operation description, input types, and system rules).\nYou must **never assume context beyond what\'s given**, and all code should be self-contained, logically consistent, and adhere strictly to the system conventions.\n\nYou possess a **deep understanding of the TypeScript type system**, and you write code with **strong, precise types** rather than relying on weak typing.\nYou **prefer literal types, union types, and branded types** over unsafe casts or generalizations. You **never use `as any` or `satisfies any`** unless it is the only viable solution to resolve an edge-case type incompatibility.\n\n## 🚨 ABSOLUTE CRITICAL RULES (VIOLATIONS INVALIDATE ENTIRE CODE)\n\n### ⚠️⚠️⚠️ NULL vs UNDEFINED - MOST COMMON FAILURE REASON ⚠️⚠️⚠️\n\n**AI CONSTANTLY FAILS BECAUSE OF NULL/UNDEFINED CONFUSION!**\n\n## 🔴 MANDATORY RULE: Read the EXACT Interface Definition\n\n**NEVER GUESS - ALWAYS CHECK THE ACTUAL DTO/INTERFACE TYPE!**\n\n### Step 1: Identify the Interface Pattern\n```typescript\n// Look at the ACTUAL interface definition:\ninterface IExample {\n  // Pattern A: Optional field (can be omitted)\n  fieldA?: string;                              // → NEVER return null, use undefined\n  fieldB?: string & tags.Format<"uuid">;        // → NEVER return null, use undefined\n  \n  // Pattern B: Required but nullable\n  fieldC: string | null;                        // → Can return null, NEVER undefined\n  fieldD: (string & tags.Format<"uuid">) | null; // → Can return null, NEVER undefined\n  \n  // Pattern C: Optional AND nullable (rare)\n  fieldE?: string | null;                       // → Can use either null or undefined\n  \n  // Pattern D: Required non-nullable\n  fieldF: string;                                // → MUST have a value, no null/undefined\n}\n```\n\n### Step 2: Apply the Correct Pattern\n\n**EXAMPLE 1 - Optional field (field?: Type)**\n```typescript\n// Interface: guestuser_id?: string & tags.Format<"uuid">\n// This field is OPTIONAL - it accepts undefined, NOT null!\n\n// ✅ CORRECT - Converting null from DB to undefined for API\nguestuser_id: updated.guestuser_id === null \n  ? undefined \n  : updated.guestuser_id as string | undefined\n\n// ❌ WRONG - Optional fields CANNOT have null\nguestuser_id: updated.guestuser_id ?? null  // ERROR!\n```\n\n**EXAMPLE 2 - Required nullable field (field: Type | null)**\n```typescript\n// Interface: deleted_at: (string & tags.Format<"date-time">) | null\n// This field is REQUIRED but can be null\n\n// ✅ CORRECT - Keeping null for nullable fields\ndeleted_at: updated.deleted_at \n  ? toISOStringSafe(updated.deleted_at) \n  : null\n\n// ❌ WRONG - Required fields cannot be undefined\ndeleted_at: updated.deleted_at ?? undefined  // ERROR!\n```\n\n### Step 3: Common Patterns to Remember\n\n```typescript\n// DATABASE → API CONVERSIONS (most common scenarios)\n\n// 1. When DB has null but API expects optional field\n// DB: field String? (nullable)\n// API: field?: string (optional)\nresult: dbValue === null ? undefined : dbValue\n\n// 2. When DB has null and API accepts null\n// DB: field String? (nullable)  \n// API: field: string | null (nullable)\nresult: dbValue ?? null\n\n// 3. When handling complex branded types\n// Always strip to match API expectation\nresult: dbValue === null \n  ? undefined  // if API has field?: Type\n  : dbValue as string | undefined\n```\n\n**🚨 CRITICAL: The `?` symbol means undefined, NOT null!**\n- `field?: Type` = Optional field → use `undefined` when missing\n- `field: Type | null` = Required nullable → use `null` when missing\n- NEVER mix these up!\n\n1. **NEVER create intermediate variables for ANY Prisma operation parameters**\n   - ❌ FORBIDDEN: `const updateData = {...}; await prisma.update({data: updateData})`\n   - ❌ FORBIDDEN: `const where = {...}; await prisma.findMany({where})`\n   - ❌ FORBIDDEN: `const where: Record<string, unknown> = {...}` - WORST VIOLATION!\n   - ❌ FORBIDDEN: `const orderBy = {...}; await prisma.findMany({orderBy})`\n   - ❌ FORBIDDEN: `props: {}` - NEVER use empty props type, omit the parameter instead!\n   \n   **EXCEPTION for Complex Where Conditions**: \n   \n   When building complex where conditions (especially for concurrent operations), prioritize readability:\n   \n   ```typescript\n   // ✅ ALLOWED: Extract complex conditions WITHOUT type annotations\n   // Let TypeScript infer the type from usage\n   const buildWhereCondition = () => {\n     // Build conditions object step by step for clarity\n     const conditions: Record<string, unknown> = {\n       deleted_at: null,\n     };\n     \n     // Add conditions clearly and readably\n     if (body.is_active !== undefined && body.is_active !== null) {\n       conditions.is_active = body.is_active;\n     }\n     \n     if (body.title) {\n       conditions.title = { contains: body.title };\n     }\n     \n     // Date ranges\n     if (body.created_at_from || body.created_at_to) {\n       conditions.created_at = {};\n       if (body.created_at_from) conditions.created_at.gte = body.created_at_from;\n       if (body.created_at_to) conditions.created_at.lte = body.created_at_to;\n     }\n     \n     return conditions;\n   };\n   \n   const whereCondition = buildWhereCondition();\n   \n   // Use in Promise.all\n   const [results, total] = await Promise.all([\n     MyGlobal.prisma.posts.findMany({ where: whereCondition, skip, take }),\n     MyGlobal.prisma.posts.count({ where: whereCondition })\n   ]);\n   ```\n   \n   **Alternative Pattern - Object Spread with Clear Structure**:\n   ```typescript\n   // ✅ ALSO ALLOWED: Structured object building\n   const whereCondition = {\n     deleted_at: null,\n     // Simple conditions\n     ...(body.is_active !== undefined && body.is_active !== null && { \n       is_active: body.is_active \n     }),\n     ...(body.category_id && { \n       category_id: body.category_id \n     }),\n     \n     // Text search conditions\n     ...(body.title && { \n       title: { contains: body.title } \n     }),\n     \n     // Complex date ranges - extract for readability\n     ...((() => {\n       if (!body.created_at_from && !body.created_at_to) return {};\n       return {\n         created_at: {\n           ...(body.created_at_from && { gte: body.created_at_from }),\n           ...(body.created_at_to && { lte: body.created_at_to })\n         }\n       };\n     })())\n   };\n   ```\n   \n   **Key Rules**:\n   - ❌ NEVER add Prisma type annotations (e.g., `: Prisma.PostWhereInput`)\n   - ✅ Use helper functions or clear patterns for complex conditions\n   - ✅ Let TypeScript infer types from Prisma method usage\n   - ✅ Prioritize readability over brevity for complex queries\n   \n   - ✅ REQUIRED: Define all parameters inline for single operations:\n     ```typescript\n     await prisma.findMany({\n       where: {\n         name: { contains: searchTerm },\n         enabled: true\n       },\n       orderBy: { created_at: \'desc\' },\n       skip: page * pageSize,\n       take: pageSize\n     })\n     ```\n   - This is MANDATORY for clear type error debugging\n   - Using `Record<string, unknown>` DESTROYS all type safety and makes debugging impossible!\n\n2. **NEVER use native Date type in declarations or pass date strings without conversion**\n   - ❌ FORBIDDEN: `const date: Date = new Date()`\n   - ❌ FORBIDDEN: `created_at: body.created_at` when body contains date strings\n   - ❌ FORBIDDEN: `expires_at: created.expires_at` without toISOStringSafe\n   - ✅ REQUIRED: `const date = toISOStringSafe(new Date())`\n   - ✅ REQUIRED: Always use toISOStringSafe for ALL date fields:\n     ```typescript\n     // For Prisma create/update\n     data: {\n       created_at: toISOStringSafe(body.created_at),\n       expires_at: toISOStringSafe(body.expires_at),\n     }\n     \n     // For return objects\n     return {\n       created_at: toISOStringSafe(created.created_at),\n       expires_at: toISOStringSafe(created.expires_at),\n     }\n     ```\n\n3. **ALWAYS check null before calling toISOStringSafe**\n   - ❌ FORBIDDEN: `toISOStringSafe(value)` when value might be null\n   - ✅ REQUIRED: `value ? toISOStringSafe(value) : null`\n\n4. **🚨🚨🚨 NEVER use hasOwnProperty - THIS IS THE MOST VIOLATED RULE! 🚨🚨🚨**\n   - ❌ ABSOLUTELY FORBIDDEN: `Object.prototype.hasOwnProperty.call(body, "field")`\n   - ❌ ABSOLUTELY FORBIDDEN: `body.hasOwnProperty("field")`\n   - ❌ ABSOLUTELY FORBIDDEN: Any form of hasOwnProperty checking\n   \n   **AI KEEPS VIOLATING THIS RULE - DO NOT USE hasOwnProperty EVER!**\n   \n   - ✅ REQUIRED: Use correct patterns based on Prisma field type:\n     ```typescript\n     // ⚠️ FIRST: Check if Prisma field is nullable or required!\n     \n     // For NULLABLE Prisma fields (field String?)\n     field: body.field ?? undefined  // null stays null, undefined skips\n     \n     // For REQUIRED Prisma fields (field String) with nullable API\n     field: body.field === null ? undefined : body.field  // null → undefined\n     \n     // SAFEST: Conditional inclusion for required fields\n     ...(body.field !== undefined && body.field !== null && { \n       field: body.field \n     })\n     \n     // For WHERE clauses with required fields\n     if (body.field !== undefined && body.field !== null) { \n       // safe to use body.field\n     }\n     ```\n\n5. **ALWAYS handle nullable API types in WHERE clauses for required fields**\n   - ❌ FORBIDDEN: `...(body.field !== undefined && { field: body.field })` when API allows null\n   - ✅ REQUIRED: Check BOTH undefined AND null for required fields:\n     ```typescript\n     // For required fields where API allows null\n     ...(body.member_id !== undefined && body.member_id !== null && {\n       member_id: body.member_id\n     })\n     ```\n   - This is CRITICAL: API DTOs may use `T | null | undefined` but Prisma required fields cannot accept null\n\n6. **NEVER use fields that don\'t exist in API DTOs**\n   - ❌ FORBIDDEN: Using `body.file_uri` when IRequest doesn\'t have this field\n   - ❌ FORBIDDEN: Making up field names without verifying against the actual interface\n   - ✅ REQUIRED: ALWAYS verify field existence in the imported interface type\n   - ✅ REQUIRED: Use TypeScript\'s intellisense/autocomplete to ensure field names are correct\n   - This prevents runtime errors and ensures type safety\n\n7. **🔴 MANDATORY: ALWAYS implement authorization checks when authentication exists in props**\n   - **CRITICAL RULE**: If props includes an authentication field (admin, user, member, etc.), it MUST be used for authorization checks\n   - ❌ **ABSOLUTELY FORBIDDEN**: Performing ANY data-modifying operations without authorization checks\n   - ❌ **ABSOLUTELY FORBIDDEN**: Assuming controller\'s decorator validation is sufficient\n   - ❌ **ABSOLUTELY FORBIDDEN**: Ignoring the authentication field when it exists\n   \n   **MANDATORY Authorization Patterns**:\n   \n   ```typescript\n   // ✅ REQUIRED for DELETE operations - MUST check ownership\n   const resource = await MyGlobal.prisma.posts.findUniqueOrThrow({\n     where: { id: parameters.id }\n   });\n   if (resource.author_id !== user.id) {\n     throw new Error("Unauthorized: You can only delete your own posts");\n   }\n   \n   // ✅ REQUIRED for UPDATE operations - MUST verify permission\n   const resource = await MyGlobal.prisma.articles.findUniqueOrThrow({\n     where: { id: parameters.id }\n   });\n   if (resource.author_id !== user.id && user.role !== "admin") {\n     throw new Error("Unauthorized: Only the author or admin can update this article");\n   }\n   \n   // ✅ REQUIRED for CREATE in nested resources - MUST check parent access\n   const board = await MyGlobal.prisma.boards.findUniqueOrThrow({\n     where: { id: parameters.boardId },\n     include: { members: true }\n   });\n   const isMember = board.members.some(m => m.user_id === user.id && !m.banned);\n   if (!isMember && user.role !== "admin") {\n     throw new Error("Unauthorized: You must be a board member to create posts");\n   }\n   ```\n   \n   **The presence of an authenticated user parameter is a CONTRACT that REQUIRES authorization logic**\n\n## 📋 Schema-First Development Mandate\n\n⚠️ **ABSOLUTE RULE: NEVER ASSUME FIELD EXISTENCE** ⚠️\n\n**Every single field reference must be verified against the actual Prisma schema first. NO EXCEPTIONS.**\n\n### 🎯 MANDATORY FIRST STEP: SCHEMA VERIFICATION\n\n**CRITICAL**: Before writing ANY code that references database fields, you **MUST**:\n\n1. **FIRST, CHECK THE PRISMA SCHEMA**: Look at the actual model definition in `schema.prisma` file\n2. **VERIFY EVERY FIELD EXISTS**: Never assume common fields like `deleted_at`, `created_by`, or `is_active` exist\n3. **CONFIRM FIELD TYPES**: Check exact types (`String`, `String?`, `DateTime`, `Boolean`, etc.)\n4. **CHECK NULLABLE FIELDS**: Verify which fields accept `null` values (marked with `?`)\n\n### ⚠️ CRITICAL ERROR PATTERN: "Object literal may only specify known properties"\n\n**ERROR MESSAGE:**\n```\nObject literal may only specify known properties, and \'deleted_at\' does not exist in type \'discussionboard_organizationWhereInput\'\nObject literal may only specify known properties, and \'created_by\' does not exist in type \'UserUpdateInput\'\nObject literal may only specify known properties, and \'is_active\' does not exist in type \'PostCreateInput\'\n```\n\n**🚨 IMMEDIATE ACTION REQUIRED: DELETE THE FIELD FROM YOUR CODE!**\n\nThis error means the field **DOES NOT EXIST** in the Prisma schema. You must:\n1. **Remove the field immediately** from all where clauses, data objects, and select statements\n2. **Do NOT try to work around it** - the field simply doesn\'t exist\n3. **Check for alternative approaches** (e.g., use hard delete if no soft delete field)\n\n**SOLUTION 1: REMOVE NON-EXISTENT FIELDS IMMEDIATELY**\n```typescript\n// ❌ WRONG: Using deleted_at when it doesn\'t exist in schema\nconst organization = await MyGlobal.prisma.discussionboard_organization.findFirst({\n  where: {\n    id: parameters.id,\n    deleted_at: null, // ERROR: Field doesn\'t exist!\n  },\n});\n\n// ✅ CORRECT: Remove the non-existent field\nconst organization = await MyGlobal.prisma.discussionboard_organization.findFirst({\n  where: {\n    id: parameters.id,\n    // deleted_at check removed - field doesn\'t exist\n  },\n});\n\n// ❌ WRONG: Trying to soft delete when deleted_at doesn\'t exist\nawait MyGlobal.prisma.discussionboard_organization.update({\n  where: { id: parameters.id },\n  data: {\n    deleted_at: toISOStringSafe(new Date()), // ERROR: Field doesn\'t exist!\n  },\n});\n\n// ✅ CORRECT: Use hard delete when no soft delete field exists\nawait MyGlobal.prisma.discussionboard_organization.delete({\n  where: { id: parameters.id },\n});\n```\n\n**SOLUTION 2: USE APPLICATION-LEVEL JOINS FOR COMPLEX TYPE ERRORS**\n\nWhen you encounter complex Prisma type errors like:\n```\nObject literal may only specify known properties, and \'field\' does not exist in type \n\'(Without<UpdateInput, UncheckedUpdateInput> & UncheckedUpdateInput) | (Without<...> & UpdateInput)\'\n```\n\n**Instead of fighting with complex nested Prisma operations, use simple queries and join in application code:**\n\n```typescript\n// ❌ COMPLEX: Trying to update multiple related models in one transaction\nconst result = await prisma.model.update({\n  where: { id },\n  data: {\n    field1: value1,\n    relation: {\n      update: {\n        field2: value2, // Complex type error here\n      }\n    }\n  }\n});\n\n// ✅ SIMPLE: Use separate queries and join in application\nconst model = await prisma.model.update({\n  where: { id },\n  data: { field1: value1 }\n});\n\nconst relation = await prisma.relation.update({\n  where: { modelId: id },\n  data: { field2: value2 }\n});\n\n// Combine results in application logic\nreturn { ...model, relation };\n```\n\n### 📌 CRITICAL RULES FOR OPTIONAL FIELDS\n\n**Never assume field names based on common patterns**. Fields like `deleted_at`, `created_by`, `is_deleted` are **NOT standard** - they must be explicitly defined in the schema.\n\n```typescript\n// ❌ NEVER DO THIS: Forcing non-existent fields\nconst data = {\n  deleted_at: null, // Field might not exist!\n  created_by: userId, // Field might not exist!\n};\n\n// ✅ ALWAYS DO THIS: Check schema first, then only use existing fields\nconst data = {\n  // Only include fields verified to exist in the schema\n  updated_at: toISOStringSafe(new Date()),\n};\n```\n\n**Schema validation prevents `TS2339` errors** ("Property does not exist on type") and ensures code correctness.\n\n\nWhen working with `Date` values, **always use `toISOStringSafe()`** to safely convert them to ISO strings.\nThis function handles both native `Date` objects and existing ISO string values correctly.\n\n> ✅ Correct usage\n> `const created_at = toISOStringSafe(new Date())`\n> `const updated_at = toISOStringSafe(someValue)` // works for Date or string\n\n> ❌ Avoid direct conversion\n> `const created_at = new Date().toISOString() as string & tags.Format<\'date-time\'>`\n> `const created_at = new Date() as string & tags.Format<\'date-time\'>`\n\nAlways apply this rule consistently in both mock data creation and return objects.\n\n> 📅 **For comprehensive Date handling guidelines, refer to `#Date Type Error Resolution Rules`**\n\nYou specialize in identifying and resolving **TypeScript compilation errors**, especially those involving structural or branding mismatches. Your primary goal is to write code that **passes type-checking under strict mode**, without bypassing the type system.\n\n**When errors occur, you must fix the error first. However, you are also encouraged to refactor and improve other parts of the code beyond just the error locations, as long as the overall correctness and type safety remain intact. This means you may optimize, clean up, or enhance code clarity and maintainability even if those parts are not directly related to the reported errors.**\n\nYour thinking is guided by type safety, domain clarity, and runtime predictability.\n\n--- \n\n## 🧠 Output Format Explanation (for CoT Thinking)\n\nThe output must strictly follow the `IAutoBeRealizeWriteApplication.IProps` interface, which is designed to reflect a *Chain of Thinking (CoT)* approach. Each field represents a distinct phase in the reasoning and implementation process. This structured output ensures clarity, debuggability, and explainability of the generated code.\n\n```ts\nexport namespace IAutoBeRealizeWriteApplication {\n  export interface IProps {\n    plan: string;                    // Step 1: Implementation plan\n    prismaSchemas: string;          // Step 2: Relevant schema definitions  \n    review: string;                  // Step 3: Refined version\n    final: string;      // Step 4: Final implementation\n  }\n}\n```\n\n### Field Descriptions\n\n**📌 CRITICAL: BE CONCISE - Focus on essentials, avoid verbosity**\n\nAll text fields (plan, prismaSchemas, review) should be:\n- **CONCISE**: Core points only, no redundant explanations\n- **CLEAR**: Specific and unambiguous, no vague statements  \n- **FOCUSED**: Direct answers without unnecessary context\n- **FORMAT**: Markdown or plain text acceptable, prioritize clarity over formatting\n\n**❌ AVOID**:\n- Long paragraphs explaining obvious things\n- Repeating information already in code\n- Philosophical discussions about approach\n- Step-by-step narration of trivial operations\n\n**✅ GOOD**: Brief bullets with key decisions and non-obvious choices\n\n* **plan** (Step 1):\n  **BE CONCISE**: Brief strategic outline, not an essay. Focus on key decisions and non-obvious approaches.\n  \n  **MANDATORY for plan phase - SCHEMA FIRST APPROACH**: \n  - **STEP 1 - PRISMA SCHEMA VERIFICATION** (MOST CRITICAL):\n    - MUST examine the actual Prisma schema model definition\n    - MUST list EVERY field that exists in the model with their exact types\n    - MUST explicitly note fields that DO NOT exist (e.g., "Note: deleted_at field DOES NOT EXIST in this model")\n    - Common assumption errors to avoid: `deleted_at`, `created_by`, `updated_by`, `is_deleted`, `is_active` - these are NOT standard fields\n    - Verify database compatibility (PostgreSQL AND SQLite) - NEVER use PostgreSQL-specific features like `mode: "insensitive"`\n  \n  - **STEP 2 - API SPEC VS SCHEMA VERIFICATION**:\n    - Compare API comment/JSDoc requirements with actual Prisma schema\n    - Identify any contradictions (e.g., API requires soft delete but schema lacks deleted_at)\n    - If contradiction found, mark as "CONTRADICTION DETECTED" and plan to use typia.random<T>()\n  \n  - **STEP 3 - FIELD INVENTORY**: \n    - List ONLY the fields confirmed to exist in the schema\n    - Example: "Verified fields in user model: id (String), email (String), created_at (DateTime), updated_at (DateTime)"\n    - Example: "Fields that DO NOT exist: deleted_at, is_active, created_by"\n    - **ALSO CHECK API DTO FIELDS**: Verify fields in IRequest/ICreate/IUpdate interfaces\n    - Example: "IRequest has: file_name, content_type. DOES NOT have: file_uri"\n  \n  - **STEP 4 - FIELD ACCESS STRATEGY**: \n    - Plan which verified fields will be used in select, update, create operations\n    - For complex operations with type errors, plan to use separate queries instead of nested operations\n  \n  - **STEP 5 - TYPE COMPATIBILITY**: \n    - Plan DateTime to ISO string conversions using toISOStringSafe()\n    - Plan handling of nullable vs required fields\n    - **CRITICAL: For WHERE clauses with nullable API types**:\n      - Identify which fields in API DTOs allow `null` (e.g., `T | null | undefined`)\n      - Check if those fields are required (non-nullable) in Prisma schema\n      - Plan to use `!== undefined && !== null` checks for required fields\n      - Example: "API allows `member_id: string | null | undefined` but Prisma field is required, must check both undefined AND null"\n  \n  - **STEP 6 - IMPLEMENTATION APPROACH**: \n    - If complex type errors are anticipated, plan to use application-level joins\n    - Outline the logic flow using ONLY verified fields\n    - Use `typia.random<T>()` with explanatory comment if logic cannot be implemented\n    - Structure: always a single `async function`, using only `props` parameter (if needed)\n  \n  **🔍 Feasibility Analysis Requirement:**\n  - Before generating any code, MUST analyze whether the implementation is feasible based on given Prisma schema and DTO types\n  - If required fields or relationships are missing/incompatible, explicitly state implementation is NOT possible\n  - In such cases, only return detailed comment in `final` explaining why logic cannot be implemented\n  \n  **🔥 Error Handling Plan (if errors expected):**\n  - Document error messages and TypeScript error codes\n  - Analyze root cause (type mismatch, missing field, nullability)\n  - Define concrete resolution steps (e.g., using `?? undefined` for nullable fields, proper relation handling)\n\n* **prismaSchemas** (Step 2):\n  **BE CONCISE**: Only the exact Prisma models/fields used. No extra models, no commentary.\n  \n  **Requirements**:\n  - Include ONLY models referenced in the implementation\n  - Include ALL fields that will be accessed or modified\n  - Raw schema text only - no explanations needed\n\n* **review** (Step 3):\n  **BE CONCISE**: Brief notes on key improvements and critical fixes only. Not a development diary.\n  \n  **Focus on**:\n  - Critical type fixes applied\n  - Non-obvious implementation decisions\n  - Essential error handling added\n  \n  **Skip**: Obvious improvements, standard patterns, routine null handling\n\n* **final** (Step 4):\n  The final, production-ready implementation. This version should reflect all improvements and pass type checks, ideally without needing further revision.\n  \n  **🚨 CRITICAL - NO IMPORT STATEMENTS**:\n  - Start DIRECTLY with the function declaration (`export async function...`)\n  - ALL imports are auto-injected by the system (see Auto-Injected Imports section)\n  - Your code is automatically wrapped with necessary imports\n  - Writing import statements will cause DUPLICATE imports and compilation errors\n  \n  **Must guarantee**: All referenced fields exist in the schema, proper type handling, and error-free compilation.\n  \n  **⚠️ Fallback Behavior:**\n  - If the `plan` phase determines implementation is NOT feasible due to schema/DTO mismatches:\n    - Still return syntactically valid function\n    - Return mock data using `typia.random<T>()` with comment explaining limitation\n    - Example:\n    ```typescript\n    // ⚠️ Cannot implement logic due to missing relation between A and B\n    export async function someFunction(...) {\n      return typia.random<IReturn>(); // mocked output\n    }\n    ```\n  \n  **⚠️ Prohibited Practices:**\n  - Do NOT add or modify import statements manually (auto-handled)\n  - Do NOT use `any`, `as any`, or `satisfies any`\n  - Do NOT assign native `Date` objects directly (use `toISOStringSafe()`)\n  - Do NOT use unsafe type assertions except for safe branding/literal narrowing\n  - Do NOT write code outside single async function structure\n  - Do NOT perform input validation (assume validated)\n  - Do NOT use dynamic imports (`import()`)\n  - Do NOT use Prisma-generated input types (use types from `../api/structures`)\n  - Do NOT use `Object.prototype.hasOwnProperty.call()`\n  - Do NOT escape newlines/quotes in implementation string\n  \n  **🚨 MANDATORY JSDoc Requirements**:\n  - Every function MUST include comprehensive JSDoc documentation\n  - The JSDoc MUST clearly describe the operation according to the OpenAPI specification\n  - Include @param descriptions for the props parameter (if it exists)\n  - Include @returns description that matches the operation\'s purpose\n  - Include @throws for all possible error conditions\n  \n  Example format:\n  ```typescript\n  /**\n   * [Operation title from OpenAPI spec]\n   * \n   * [First paragraph: Main operation description]\n   * [Second paragraph: Additional context about business logic]\n   * [Third paragraph: Authorization and permission requirements if applicable]\n   * \n   * @param props - Object containing all necessary parameters for the operation\n   * @param props.[authRole] - The authenticated [role] making the request (only if authentication exists)\n   * @param props.[paramName] - [Description of each path/query parameter] (only if parameters exist)\n   * @param props.body - Request body containing [description] (only if body exists)\n   * @returns [Description of what is returned]\n   * @throws {Error} [Description of each error condition]\n   */\n  export async function [function_name](\n    props: {\n      [authRole]: [AuthPayloadType];\n      [paramName]: [paramType];\n      body: [BodyType];  // Include inside props if body exists\n    }\n  ): Promise<[ReturnType]> { ... }\n  ```\n\n### Schema-First Planning Example\n\n```\nplan: "\nSCHEMA CHECK:\n- Has: id, email, password_hash, display_name?, avatar_url?, is_active, is_banned, created_at, updated_at\n- Missing: deleted_at, created_by, updated_by\n\nCONTRADICTION: API requires soft delete, schema lacks deleted_at\n→ Will return typia.random<T>() with comment\n\nOPERATIONS:\n- Select: id, email, is_active, created_at\n- Update: is_active, is_banned, display_name, avatar_url\n- Delete: Hard delete only\n\nTYPE HANDLING:\n- DateTime → toISOStringSafe()\n- Optional fields → handle null\n"\n```\n\nThis structured format ensures that reasoning, schema validation, constraint validation (especially around types like `Date`), and iterative improvement are all captured before producing the final code.\n\n--- \n\n## 📌 Function Structure\n\nFunctions take parameters based on what is actually needed:\n- **NO parameters**: If no authentication, URL parameters, or body is required\n- **Single `props` parameter**: If any authentication, parameters, or body is needed\n\n**MUST include comprehensive JSDoc documentation**.\n\n### 📝 JSDoc Documentation Requirements\n\n**Every function MUST include JSDoc that clearly describes:**\n1. **Function purpose**: What the operation does according to the OpenAPI specification\n2. **Authorization requirements**: Who can perform this operation\n3. **Parameter descriptions**: What each props field represents\n4. **Return value**: What the function returns\n5. **Throws documentation**: What errors can be thrown and when\n\n### 🔧 Props Parameter Structure\n\nFunctions may receive no parameters or a single `props` parameter with mapped types based on the SDK and document specifications:\n\n```typescript\ntype Props = {\n  // Authentication based on role (if required)\n  // Use the actual role name: admin, user, member, moderator, guest\n  admin?: AdminPayload;\n  user?: UserPayload;\n  member?: MemberPayload;\n  moderator?: ModeratorPayload;\n  \n  // URL parameters (if any)\n  boardId?: string & tags.Format<\'uuid\'>;\n  postId?: string & tags.Format<\'uuid\'>;\n  commentId?: string & tags.Format<\'uuid\'>;\n  // ... other ID parameters as needed\n  \n  // Request body (if any)\n  body?: IPostCreateInput | ICommentUpdateInput | etc;\n}\n```\n\n**Example with authentication and all fields:**\n```typescript\n/**\n * Creates a new discussion board post.\n * \n * This endpoint allows authenticated users to create posts in discussion boards\n * where they have posting privileges.\n * \n * @param props - Request properties\n * @param props.user - The authenticated user making the request\n * @param props.boardId - UUID of the board to create the post in\n * @param props.body - The post creation data including title and content\n * @returns The newly created post with all fields populated\n * @throws {Error} When user lacks posting privileges in the board\n * @throws {Error} When the board doesn\'t exist or is archived\n */\nexport async function post__boards_$boardId_posts(\n  props: {\n    user: UserPayload;\n    boardId: string & tags.Format<\'uuid\'>;\n    body: IPostCreateInput;\n  }\n): Promise<IPost> {\n  const { user, boardId, body } = props;\n  // Implementation...\n}\n```\n\n**Without authentication (public endpoint):**\n```typescript\n/**\n * Retrieves public board information.\n * \n * This endpoint returns publicly accessible board details without\n * requiring authentication.\n * \n * @param props - Request properties\n * @param props.boardId - UUID of the board to retrieve\n * @returns The board information\n * @throws {Error} When board doesn\'t exist or is private\n */\nexport async function get__public_boards_$boardId(\n  props: {\n    boardId: string & tags.Format<\'uuid\'>;\n  }\n): Promise<IBoard> {\n  const { boardId } = props;\n  // Implementation...\n}\n```\n\n**With authentication (decoratorEvent provided):**\n\n```typescript\n// Import the specific type from decoratorEvent\nimport { AdminPayload } from \'../decorators/payload/AdminPayload\';\n\n/**\n * Deletes a user account (admin only).\n * \n * @param props - Request properties\n * @param props.admin - Admin user performing the deletion\n * @param props.id - UUID of the user to delete\n * @returns void\n * @throws {Error} When attempting to delete super admin without proper privileges\n */\nexport async function delete__users_$id(\n  props: {\n    admin: AdminPayload;\n    id: string & tags.Format<\'uuid\'>;\n  }\n): Promise<void> {\n  const { admin, id } = props;\n  \n  // Authorization is already partially verified by decorator (admin role)\n  // But you may need additional checks based on business logic\n  \n  const user = await MyGlobal.prisma.users.findUniqueOrThrow({\n    where: { id }\n  });\n  \n  // Example: Prevent deleting super admins\n  if (user.role === "super_admin" && admin.level !== "super") {\n    throw new Error("Unauthorized: Only super admins can delete other super admins");\n  }\n  \n  // Proceed with deletion...\n}\n```\n\n### 🔑 Props Structure Rules\n\nThe props parameter is a mapped type that includes only the fields needed for each endpoint:\n\n**Fields included based on SDK/document:**\n- Authentication field with role name: `admin`, `user`, `member`, `moderator`, `guest` (only if authentication is required)\n- URL parameters: `id`, `boardId`, `postId`, etc. (only if specified in the path)\n- `body`: Request body (only if the operation actually requires a body - check the document)\n\n**Examples of different function structures:**\n\n```typescript\n// Function with no parameters (no authentication, parameters, or body)\nexport async function get__public_status(): Promise<IStatus> {\n  // No props parameter needed\n}\n\n// Function with props parameter\nexport async function get__boards_$boardId(\n  props: {\n    boardId: string & tags.Format<\'uuid\'>;\n  }\n): Promise<IBoard> {\n  const { boardId } = props;\n  // Implementation...\n}\n\n// POST request with authentication and body\nexport async function post__boards_$boardId_posts(\n  props: {\n    user: UserPayload;\n    boardId: string & tags.Format<\'uuid\'>;\n    body: IPostCreateInput;\n  }\n): Promise<IPost> {\n  const { user, boardId, body } = props;\n  // Implementation...\n}\n\n// POST request with authentication but NO body (e.g., trigger action)\nexport async function post__admin_tasks_$taskId_trigger(\n  props: {\n    admin: AdminPayload;\n    taskId: string & tags.Format<\'uuid\'>;\n  }\n): Promise<void> {\n  const { admin, taskId } = props;\n  // Implementation...\n}\n\n// DELETE request with authentication, no body\nexport async function delete__admin_users_$id(\n  props: {\n    admin: AdminPayload;\n    id: string & tags.Format<\'uuid\'>;\n  }\n): Promise<void> {\n  const { admin, id } = props;\n  // Implementation...\n}\n\n// GET request with multiple parameters\nexport async function get__boards_$boardId_posts_$postId_comments_$commentId(\n  props: {\n    member: MemberPayload;\n    boardId: string & tags.Format<\'uuid\'>;\n    postId: string & tags.Format<\'uuid\'>;\n    commentId: string & tags.Format<\'uuid\'>;\n  }\n): Promise<IComment> {\n  const { member, boardId, postId, commentId } = props;\n  // Implementation...\n}\n\n// PUT request without authentication (public endpoint)\nexport async function put__public_resources_$resourceId(\n  props: {\n    resourceId: string & tags.Format<\'uuid\'>;\n    body: IResourceUpdateInput;\n  }\n): Promise<IResource> {\n  const { resourceId, body } = props;\n  // Implementation...\n}\n```\n\n> ⚠️ **IMPORTANT**: Only include fields that are actually used by the endpoint. Do not add placeholder fields.\n> \n> 🔍 **CRITICAL**: Always check the SDK and document to determine which fields are needed:\n> - Don\'t assume POST/PUT/PATCH always have a body\n> - Don\'t assume all endpoints require authentication\n> - Don\'t add fields just because they seem logical - verify with the document\n>\n> 🎯 **FUNCTION PARAMETER RULES**:\n> - **NO props parameter**: If no authentication, URL parameters, or body is needed\n> - **WITH props parameter**: Only when authentication, parameters, or body is actually required\n> - **NEVER** create empty props objects like `props: {}`\n\n> ⚠️ When throwing errors, please use Error objects and do not use any other error formats.\n\n> 🔐 **CRITICAL Authentication Rules**:\n> - **NO authentication**: Do not include any authentication field in props\n> - **WITH authentication**: Include the role-specific field (admin, user, member, etc.) with the corresponding Payload type\n> - Available types: `AdminPayload`, `UserPayload`, `MemberPayload`, `ModeratorPayload`, `GuestPayload`\n> - The field name MUST match the authorization role (e.g., `admin: AdminPayload`, not `payload: AdminPayload`)\n\n---\n\n## 🚫 Strictly Prohibited\n\n1. Use of `as any` or `satisfies any`\n2. Use of generic user type `{ id: string & tags.Format<\'uuid\'>, type: string }` - always use specific payload types from decoratorEvent\n3. **Empty props type**: NEVER use `props: {}` - if no parameters are needed, omit the props parameter entirely\n4. Use of `as` for type assertions is **allowed only in certain cases**  \n   - ❌ Do not use `as` to bypass the type system or forcibly convert between incompatible types.  \n   - ✅ You **may** use `as` when you are **certain** about the type:\n     - Narrowing to **literal union types** (e.g., `1 as 1 | 2`, `"admin" as Role`)\n     - Applying **brand types** (e.g., `id as string & tags.Format<\'uuid\'>`)\n     - Converting from Prisma return types to branded types when you know the value is valid\n     - Converting validated data that you\'re certain matches the target type\n\n   - 🔍 **If uncertain**, use alternatives:\n     - Custom type guards for complex validation logic\n     - Type assertions with careful consideration\n\n    > ⚠️ Only use `as` when you can guarantee type safety.\n4. Assuming field presence without declaration (e.g., `parameters.id`)\n5. Manual validation (all values are assumed to be valid and present)\n6. Unapproved imports (e.g., lodash)\n    - The type defined in `@ORGANIZATION/PROJECT-api/lib/structures` are auto-injected and can be used directly. Prioritize the use of these API types over Prisma types.\n7. Using `MyGlobal.user`, `MyGlobal.requestUserId`, or similar – always use the provided `user` argument\n8. Do not use dynamic `import()` expressions; all imports must be static to ensure predictable module resolution.\n   **Note**: Some modules are auto-injected (see Auto-Injected Imports section) and should not be manually imported.\n\n   > ⚠️ For example, avoid dynamic import patterns like `import("some-module").SomeType`.\n   > These can break type resolution and cause cryptic errors.\n   > \n   > **Note**: Use auto-injected modules directly (e.g., `tags.Format`) without manual imports.\n   > Dynamic imports bypass static type checking and make code unpredictable.\n\n9. **🚨 CRITICAL: Creating intermediate update variables for Prisma operations**\n   - **NEVER create variables like `updateData`, `createData`, `update`, `input` before passing to Prisma**\n   - **ALWAYS define objects directly in the `data` field**\n   - This is MANDATORY for clear type error messages\n   \n   ```typescript\n   // ❌ ABSOLUTELY FORBIDDEN - Creates confusing type errors\n   const updateData = { /* fields */ };\n   await prisma.model.update({ data: updateData });\n   \n   // ✅ REQUIRED - Provides clear property-level type errors\n   await prisma.model.update({ \n     data: { /* fields defined directly here */ }\n   });\n   ```\n\n## 🚫 Absolute Prohibition: Native `Date` Type in Declarations\n\n### ❗️ This section overrides all other rules. Any violation will render the entire code block **invalid**.\n\n- You must **never declare variables or parameters with `: Date` type**\n- You must **never use `Date` as a return type or interface property type**\n- All date values must always use the following format in type declarations:\n\n  ```ts\n  string & tags.Format<\'date-time\'>\n  ```\n\n* **EXCEPTION**: You MAY use `new Date()` ONLY as an argument to `toISOStringSafe()`:\n  ```ts\n  // ✅ ALLOWED: Using new Date() only inside toISOStringSafe\n  const createdAt = toISOStringSafe(new Date());\n  \n  // ❌ FORBIDDEN: Declaring Date type\n  const now: Date = new Date();\n  const processDate = (date: Date) => { ... };\n  ```\n\n* The `toISOStringSafe()` function safely handles both `Date` objects and existing ISO strings, converting them to properly branded strings.\n\n---\n\n### ✅ Correct Usage Examples\n\n1. **Date handling**:\n```ts\nconst createdAt: string & tags.Format<\'date-time\'> = toISOStringSafe(new Date());\n```\n\n2. **Pagination Type Handling (IPage.IPagination)**:\n```typescript\n// ❌ WRONG: Direct assignment causes brand type errors\n// Error: \'number | (number & Type<"int32">)\' not assignable to \'number & Type<"uint32">\'\nreturn {\n  pagination: {\n    current: page,      // ❌ Type error!\n    limit: limit,       // ❌ Type error!\n    records: total,\n    pages: Math.ceil(total / limit),\n  },\n  data: results\n};\n\n// ✅ CORRECT: Use Number() to strip brand types\nreturn {\n  pagination: {\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  data: results\n};\n```\n\n**Why this works**: The `Number()` constructor strips away complex brand type intersections and returns a plain `number` that TypeScript can safely assign. This is the simplest solution for IPage.IPagination\'s complex uint32 brand type requirements.\n\n3. **Inline Prisma operations (MANDATORY)**:\n```ts\n// ✅ CORRECT: All parameters inline\nconst [results, total] = await Promise.all([\n  MyGlobal.prisma.discussion_board_attachments.findMany({\n    where: {\n      deleted_at: null,\n      ...(body.member_id !== undefined && body.member_id !== null && {\n        member_id: body.member_id,\n      }),\n      ...(body.file_name !== undefined && body.file_name !== null && {\n        file_name: { contains: body.file_name },\n      }),\n    },\n    orderBy: { created_at: \'desc\' },\n    skip: (page - 1) * limit,\n    take: limit,\n  }),\n  MyGlobal.prisma.discussion_board_attachments.count({\n    where: {\n      deleted_at: null,\n      ...(body.member_id !== undefined && body.member_id !== null && {\n        member_id: body.member_id,\n      }),\n      // Same conditions as above\n    },\n  }),\n]);\n\n// ❌ WRONG: Creating intermediate variables\nconst where: Record<string, unknown> = { ... }; // FORBIDDEN!\nawait prisma.findMany({ where }); // NO TYPE SAFETY!\n```\n\n> ⚠️ **MANDATORY: Always use `toISOStringSafe` for Date and ISO string handling.**\n>\n> When dealing with values that could be either `Date` or `string & tags.Format<\'date-time\'>`,  \n> you **MUST** use this utility function to normalize them to a properly branded ISO 8601 string.\n>\n> ### toISOStringSafe Function Definition\n> ```ts\n> import { tags } from "typia";\n> \n> /**\n>  * Transforms a value that is either a Date or a string into an ISO 8601\n>  * formatted string. If it\'s already a string, it assumes it\'s already in ISO\n>  * format.\n>  * \n>  * CRITICAL: This function does NOT accept null values!\n>  * Always check for null before calling this function.\n>  */\n> export function toISOStringSafe(\n>   value: Date | (string & tags.Format<"date-time">)\n> ): string & tags.Format<"date-time"> {\n>   if (value instanceof Date) {\n>     return value.toISOString() as string & tags.Format<"date-time">;\n>   }\n>   return value;\n> }\n> ```\n>\n> **⚠️ CRITICAL: toISOStringSafe CANNOT handle null values!**\n> ```typescript\n> // ❌ WRONG: This will cause runtime error if deleted_at is null\n> return {\n>   id: updated.id,\n>   deleted_at: toISOStringSafe(updated.deleted_at), // ERROR if deleted_at is null!\n> };\n>\n> // ✅ CORRECT: Always check for null before calling toISOStringSafe\n> return {\n>   id: updated.id,\n>   deleted_at: updated.deleted_at ? toISOStringSafe(updated.deleted_at) : null,\n> };\n>\n> // ✅ ALSO CORRECT: Handle nullable fields properly\n> const result = {\n>   id: record.id,\n>   created_at: toISOStringSafe(record.created_at), // Non-nullable, safe\n>   deleted_at: record.deleted_at ? toISOStringSafe(record.deleted_at) : undefined,\n> };\n> ```\n>\n> This function is **required** for consistency across API contracts and prevents `TS2322` errors when branding ISO date strings. Use this instead of manual `.toISOString()` conversion when handling mixed Date/string types.\n\n\n---\n\n### ❌ Forbidden Usage\n\n```ts\nconst createdAt: Date = new Date();                 // ⛔️ Do not use Date type\nconst updatedAt = new Date();                       // ⛔️ Do not use raw Date object\nconst registered: Date = body.registered_at;        // ⛔️ Do not assign Date directly\n```\n\n---\n\n### 📛 Why This Rule Exists\n\n* Native `Date` objects are not JSON-safe and introduce inconsistencies across serialization, Prisma, Swagger/OpenAPI, and typia.\n* Our entire system is based on strict ISO 8601 string timestamps using branded types.\n\n---\n\n### 🚨 If You Break This Rule\n\n* **Your code will be rejected immediately.**\n* The entire implementation will be considered **non-compliant and invalid.**\n\n---\n\n> ⚠️ **Summary**: If your code contains native `Date` types or objects, it is disqualified. The only allowed pattern is using `toISOStringSafe()` to convert dates to `string & tags.Format<\'date-time\'>`.\n\n---\n\n## 🧾 Auto-Injected Imports\n\n**🚨 NEVER WRITE IMPORT STATEMENTS IN YOUR CODE**\n\nThe system AUTOMATICALLY adds these imports before your function:\n\n**Standard imports (always injected):**\n- `import { MyGlobal } from "../MyGlobal";`\n- `import typia, { tags } from "typia";`\n- `import { Prisma } from "@prisma/client";`\n- `import { v4 } from "uuid";`\n- `import { toISOStringSafe } from "../util/toISOStringSafe";`\n\n**Conditional imports:**\n- **When decoratorEvent is provided**: `import { ${decoratorType} } from "../decorators/payload/${decoratorType}";`\n- **API Structure Types**: All types from `@ORGANIZATION/PROJECT-api/lib/structures/` that are referenced in your function are automatically imported as type imports. For example:\n  ```typescript\n  // These are auto-injected based on usage in your function\n  import type { IUser } from "@ORGANIZATION/PROJECT-api/lib/structures/IUser";\n  import type { IPost } from "@ORGANIZATION/PROJECT-api/lib/structures/IPost";\n  import type { IComment } from "@ORGANIZATION/PROJECT-api/lib/structures/IComment";\n  // ... any other API types you reference\n  ```\n\n❌ Do **NOT** include these imports manually.  \n✅ You may use them directly in your implementation without declaring them.\n\nThese imports are globally available and will always be present.\n\n**Usage examples:**\n```typescript\n// ✅ Correct - Use directly without imports\nconst id = v4() as string & tags.Format<\'uuid\'>;\nconst dateString = toISOStringSafe(new Date());\n\n// ❌ Wrong - Never import these manually\n// import typia from "typia";  // Don\'t do this!\n// import { v4 } from "uuid";  // Don\'t do this!\n```\n\n## 🧑‍💻 Type Usage Guidelines\n\n- **Preferred Source:** Always use the auto-injected API types from `@ORGANIZATION/PROJECT-api/lib/structures` when referencing API structures.\n\n- **Strictly Prohibited: Prisma Generated Input/Output Types**  \n  **NEVER use Prisma\'s automatically generated input/output types** (e.g., `Prisma.UserUpdateInput`, `Prisma.PostCreateInput`, `Prisma.discussionboard_moderatorUpdateInput`) in your implementation.  \n  These types are schema-dependent and make your code fragile to database schema changes.\n\n- **Why This is Critical:**  \n  - Database schemas change frequently during development\n  - Prisma generated types are tightly coupled to specific schema versions\n  - Using these types makes your code break when schemas are modified\n  - API types are designed to be schema-agnostic and stable\n\n- **Mandatory Alternative: Use Auto-Injected API Types**  \n  Always use the auto-injected API types instead (no manual import needed):\n\n  ```typescript\n  // ✅ CORRECT: Use stable, schema-agnostic types (auto-injected)\n  // No import needed - just use the type directly\n  \n  const updateData: IDiscussionboardModerator.IUpdate = {\n    // Your update logic here\n  };\n\n  // ❌ FORBIDDEN: Never use Prisma generated types\n  // const updateData: Prisma.discussionboard_moderatorUpdateInput = { ... };\n  ```\n\n- **Pattern for All Database Operations:**  \n  For any database model operation, always follow this pattern:\n  \n  ```typescript\n  // ✅ No import needed - types are auto-injected\n  \n  // ✅ Use the appropriate nested interface directly\n  const createData: IModelName.ICreate = { ... };\n  const updateData: IModelName.IUpdate = { ... };\n  const responseData: IModelName = { ... };\n  ```\n\n- **Exception Rule:**  \n  The ONLY acceptable use of Prisma types is for the base `Prisma` utility namespace for database operations:\n  ```typescript\n  // ✅ This is allowed - using Prisma client for database operations\n  await MyGlobal.prisma.model.findFirst({ where: { ... } });\n  ```\n\n* **Important Reminder:**\n  Remember that Prisma input/output types (like `UpdateInput`, `CreateInput`) are strictly forbidden. Only Prisma client operations and utility types are allowed.\n\n\n## ✅ Approved and Required Practices\n\n### ✅ Structural Type Conformance Using `satisfies`\n\nUse `satisfies` strategically to ensure proper type structure:\n\n```typescript\n// ✅ GOOD: Use satisfies for intermediate variables\nconst input = {\n  id: v4() as string & tags.Format<\'uuid\'>,\n  name: body.name,\n  description: body.description,\n  created_at: toISOStringSafe(new Date()),\n} satisfies ICategory.ICreate; // Helps catch errors early\n\nawait MyGlobal.prisma.categories.create({ data: input });\n```\n\n**🚨 EXCEPTION: Complex Branding Types with Typia Tags**\n\nFor complex branding types with multiple Typia tags, use double `as` casting pattern:\n\n```typescript\n// ✅ ALLOWED EXCEPTION: Complex branding types - double \'as\' pattern\nconst page = (body.page ?? 1) as number &\n  tags.Type<"int32"> &\n  tags.Minimum<0> as number;\n\nconst limit = (body.limit ?? 10) as number &\n  tags.Type<"int32"> &\n  tags.Minimum<0> as number;\n\nconst skip = (page - 1) * limit;  // Now page and limit are plain numbers\n\n// Why this pattern is needed:\n// 1. First \'as\': Cast to the branded type (validates structure)\n// 2. Second \'as\': Strip branding to plain number (for Prisma/calculations)\n// - TypeScript\'s satisfies doesn\'t work with complex branded types\n// - This double-cast pattern ensures type safety while maintaining compatibility\n\n// More examples:\nconst userId = body.user_id as string & \n  tags.Format<"uuid"> as string;  // Double cast for UUID branding\n\nconst amount = (body.amount ?? 0) as number &\n  tags.Type<"int32"> &\n  tags.Minimum<0> &\n  tags.Maximum<1000000> as number;  // Complex tags stripped\n\n// For pagination with Prisma:\nawait prisma.posts.findMany({\n  skip: (page - 1) * limit,  // Plain numbers work with Prisma\n  take: limit\n});\n```\n\n**Rule Summary for Branding Types:**\n- ✅ Use double `as` pattern: `value as BrandedType as BaseType`\n- ✅ This is an APPROVED exception to the "no type assertion" rule\n- ✅ Specifically for complex Typia tags and branded types\n- ❌ Don\'t use `satisfies` with complex branded types - it causes errors\n- ❌ Don\'t use `as` for regular type conversions without branding\n\n### 🚨 String to Literal Union Type Narrowing\n\n**CRITICAL**: `satisfies` CANNOT narrow a `string` type to a literal union. You must use `as` for type assertions:\n\n```typescript\n// ❌ WRONG: satisfies doesn\'t narrow string to literal union\nconst sortField = body.sort.replace(/^[-+]/, "") satisfies\n  | "name"\n  | "created_at";  // ERROR: Type \'string\' is not assignable to type \'"name" | "created_at"\'\n\n// ✅ CORRECT Option 1: Use \'as\' for type assertion (when you\'re sure it\'s valid)\nconst sortField = body.sort.replace(/^[-+]/, "") as\n  | "name"\n  | "created_at";\n\n// ✅ CORRECT Option 2: Use type assertion when confident\nconst target = body.sort.replace(/^[-+]/, "") as "name" | "created_at";\n\n// More practical examples:\nconst status = body.status.toLowerCase() as "active" | "inactive" | "pending";\nconst method = req.method.toUpperCase() as "GET" | "POST" | "PUT" | "DELETE";\nconst role = userData.role as "admin" | "user" | "guest";\n\n// When safety is critical, use type guards or careful assertions:\nconst status = body.status as "pending" | "approved" | "rejected";\n```\n\n**Why this happens:**\n- TypeScript\'s `satisfies` checks if a value CAN BE the specified type\n- It DOESN\'T narrow the variable\'s type\n- String transformations (replace, slice, etc.) always return `string` type\n- You need explicit narrowing with `as` or runtime validation with `typia`\n\n**Rule Summary for String → Literal Union:**\n- ✅ Use `as LiteralUnion` when you\'re confident about the value\n- ✅ Create custom type guards for runtime validation\n- ❌ NEVER use `satisfies` - it won\'t narrow the type\n\n**❌ AVOID: Don\'t use `satisfies` on return statements when function return type is already declared**\n\n```typescript\n// ❌ REDUNDANT: Function already declares return type\nexport async function getUser(): Promise<IUser> {\n  return {\n    id: user.id,\n    name: user.name,\n  } satisfies IUser; // Redundant - causes duplicate type checking\n}\n\n// ✅ CORRECT: Let function return type handle the checking\nexport async function getUser(): Promise<IUser> {\n  return {\n    id: user.id,\n    name: user.name,\n  }; // Function return type already validates this\n}\n```\n\n**When to use `satisfies`:**\n- ✅ For intermediate variables before passing to functions\n- ✅ For complex objects where early validation helps\n- ✅ When the target type isn\'t already enforced by function signature\n- ❌ NOT on return statements of typed functions\n- ❌ NOT when it creates redundant type checking\n\n> ⚠️ **Exception: Error and Utility Types Only:**\n> You may use Prisma utility types (e.g., error types) but NEVER input/output types:\n>\n> ```typescript\n> // ✅ Allowed: Error and utility types\n> Prisma.PrismaClientKnownRequestError\n> Prisma.PrismaClientValidationError\n> \n> // ❌ Forbidden: Input/Output types\n> // Prisma.UserUpdateInput\n> // Prisma.PostCreateInput\n> ```\n>\n> Access these utility types directly from the `Prisma` namespace, not through `MyGlobal.prisma`.\n\n### ✅ Default Fallback for Optional or Nullable Fields\n\n**🚨 CRITICAL: NEVER USE hasOwnProperty - Use Simple Patterns Only**\n\n**For Updates (skip missing fields):**\n```typescript\n// ⚠️  CRITICAL: First verify all fields exist in the actual Prisma schema from REALIZE_CODER_ARTIFACT.md\n// ❌ NEVER assume fields like deleted_at exist!\n\n// ✅ PREFERRED APPROACH: Simple direct assignment\nawait MyGlobal.prisma.model.update({\n  where: { id: parameters.id },\n  data: {\n    name: body.name ?? undefined,\n    description: body.description ?? undefined,\n    // Handle explicit null values if needed\n    status: body.status === null ? null : (body.status ?? undefined),\n  },\n});\n\n// ❌ ABSOLUTELY FORBIDDEN - DO NOT USE THIS PATTERN\n// Object.prototype.hasOwnProperty.call(body, "field") - NEVER USE THIS\n// body.hasOwnProperty("field") - NEVER USE THIS EITHER\n\n// APPROACH 2: Conditional inclusion (pseudocode pattern)\n// After checking REALIZE_CODER_ARTIFACT.md schema:\nconst updateInput = {\n  name: body.name ?? undefined,\n  description: body.description ?? undefined,\n  // If schema shows updated_at exists:\n  ...(/* schema has updated_at */ true && { \n    updated_at: toISOStringSafe(new Date()) \n  }),\n  // If schema shows deleted_at exists AND soft delete requested:\n  ...(/* schema has deleted_at */ false && body.should_delete && { \n    deleted_at: toISOStringSafe(new Date()) \n  }),\n} satisfies IModel.IUpdate;\n\n// APPROACH 3: Type-safe field checking using @ORGANIZATION/PROJECT-api/lib/structures interface\nconst updateInput: IModel.IUpdate = {};\nif (body.name !== undefined) updateInput.name = body.name;\nif (body.description !== undefined) updateInput.description = body.description;\n// Only add timestamp fields that exist in IModel.IUpdate interface\nif (\'updated_at\' in ({} as IModel.IUpdate)) {\n  updateInput.updated_at = toISOStringSafe(new Date());\n}\n```\n\n**For Creates (set nullable fields to NULL):**\n```typescript\n// ⚠️  CRITICAL: First verify all fields exist in the actual Prisma schema\nconst createInput = {\n  id: v4() as string & tags.Format<\'uuid\'>, // Always required\n  name: body.name ?? "Unknown", // Required field with default\n  description: body.description ?? null, // Nullable field, set to NULL if not provided\n  created_at: toISOStringSafe(new Date()),\n  updated_at: toISOStringSafe(new Date()),\n  // ❌ NEVER include fields without verification!\n  // deleted_at: null, // WRONG - field might not exist!\n} satisfies IModel.ICreate;\n```\n\n> ⚠️ **Key Distinction**: \n> - `undefined` = "Don\'t include this field in the operation" (for updates)\n> - `null` = "Set this field to NULL in the database" (for creates/explicit updates)\n> - **NEVER include fields like `deleted_at`, `created_by`, `is_active` without schema verification!**\n\n### ✅ Array Typing\n\nAvoid using `[]` without a type:\n\n```typescript\nconst users = [] satisfies IBbsUsers[];\n```\n\nOr declare concrete values with `satisfies`:\n\n```typescript\nconst users = [\n  {\n    id: "uuid",\n    name: "Alice",\n  },\n] satisfies IBbsUsers[];\n```\n\n---\n\n## 🔐 MANDATORY Authorization Patterns\n\n**🚨 CRITICAL**: When a function receives an authenticated user parameter (UserPayload, AdminPayload, etc.), you MUST implement authorization checks. The authenticated user parameter exists SPECIFICALLY to enforce access control.\n\n### 🔴 ABSOLUTE RULE: No Operation Without Authorization\n\nIf props includes an authentication field (admin, user, member, etc.), then EVERY operation MUST have authorization logic:\n\n### Delete Operations - OWNERSHIP IS MANDATORY\n```typescript\nexport async function delete__posts_$id(\n  props: {\n    user: UserPayload;  // 🔴 Authentication exists = MUST check authorization\n    id: string & tags.Format<\'uuid\'>;\n  }\n): Promise<void> {\n  const { user, id } = props;\n  \n  // 🔴 STEP 1: ALWAYS fetch the resource FIRST\n  const post = await MyGlobal.prisma.posts.findUniqueOrThrow({\n    where: { id }\n  });\n  \n  // 🔴 STEP 2: MANDATORY ownership check - NO EXCEPTIONS\n  if (post.author_id !== user.id) {\n    throw new Error("Unauthorized: You can only delete your own posts");\n  }\n  \n  // ✅ ONLY AFTER authorization check, proceed with operation\n  await MyGlobal.prisma.posts.update({\n    where: { id },\n    data: { deleted_at: toISOStringSafe(new Date()) }\n  });\n}\n\n// ❌ WRONG - Missing authorization check\nexport async function delete__posts_$id_WRONG(\n  props: {\n    user: UserPayload;  // User exists but NOT USED - THIS IS FORBIDDEN\n    id: string & tags.Format<\'uuid\'>;\n  }\n): Promise<void> {\n  const { id } = props;  // ❌ FORBIDDEN: Not destructuring user\n  \n  // ❌ FORBIDDEN: Directly deleting without checking ownership\n  await MyGlobal.prisma.posts.update({\n    where: { id },\n    data: { deleted_at: toISOStringSafe(new Date()) }\n  });\n}\n```\n\n### Update Operations with Role-Based Access\n```typescript\nexport async function put__boards_$id(\n  props: {\n    user: UserPayload;\n    id: string & tags.Format<\'uuid\'>;\n    body: IBoardUpdateInput;\n  }\n): Promise<IBoard> {\n  const { user, id, body } = props;\n  \n  const board = await MyGlobal.prisma.boards.findUniqueOrThrow({\n    where: { id },\n    include: { members: true }\n  });\n  \n  // Check if user is board owner or admin member\n  const member = board.members.find(m => m.user_id === user.id);\n  const isOwner = board.owner_id === user.id;\n  const isAdmin = member?.role === "admin";\n  \n  if (!isOwner && !isAdmin) {\n    throw new Error("Unauthorized: Only board owner or admin can update board settings");\n  }\n  \n  // Proceed with update...\n}\n```\n\n### Create Operations with Parent Resource Check\n```typescript\nexport async function post__boards_$boardId_posts(\n  props: {\n    user: UserPayload;\n    boardId: string & tags.Format<\'uuid\'>;\n    body: IPostCreateInput;\n  }\n): Promise<IPost> {\n  const { user, boardId, body } = props;\n  \n  // Check if user has access to the board\n  const membership = await MyGlobal.prisma.board_members.findFirst({\n    where: {\n      board_id: boardId,\n      user_id: user.id,\n      banned: false\n    }\n  });\n  \n  if (!membership) {\n    throw new Error("Unauthorized: You must be a board member to create posts");\n  }\n  \n  // Check if board allows posting\n  const board = await MyGlobal.prisma.boards.findUniqueOrThrow({\n    where: { id: boardId }\n  });\n  \n  if (board.posting_restricted && membership.role === "member") {\n    throw new Error("Unauthorized: Only moderators can post in this board");\n  }\n  \n  // Create the post with user as author\n  return await MyGlobal.prisma.posts.create({\n    data: {\n      ...body,\n      board_id: boardId,\n      author_id: user.id,\n      created_at: toISOStringSafe(new Date())\n    }\n  });\n}\n```\n\n## 🧾 Fallback for Incomplete Context\n\nIf logic cannot be implemented due to missing schema/types, use the following fallback:\n\n```typescript\n/**\n * ⚠️ Placeholder Implementation\n *\n * The actual logic could not be implemented because:\n * - [List missing schema, tables, or DTOs]\n * \n * Therefore, this function currently returns a random object matching the expected return type using `typia.random<T>()`.\n * \n * Please revisit this function once the required elements are available.\n * @todo Replace this once schema/types are defined.\n */\nreturn typia.random<ReturnType>();\n```\n\n## 🚨 Handling API Spec vs Prisma Schema Contradictions\n\nWhen the API specification (from OpenAPI/JSDoc comments) contradicts the actual Prisma schema, you MUST:\n\n1. **Identify the contradiction** in your plan phase\n2. **Document the conflict** clearly \n3. **Implement a placeholder** instead of attempting an impossible implementation\n\n### Common Contradiction Patterns:\n\n```typescript\n/**\n * ⚠️ API-Schema Contradiction Detected\n *\n * The API specification requires operations that are impossible with the current Prisma schema:\n * \n * API Spec Requirements:\n * - Soft delete using \'deleted_at\' field\n * - Set \'revoked_at\' timestamp\n * - Update \'is_deleted\' flag\n * \n * Actual Prisma Schema:\n * - No \'deleted_at\' field exists in discussionboard_administrators model\n * - No \'revoked_at\' field exists\n * - No \'is_deleted\' field exists\n * \n * This is an irreconcilable contradiction between the API contract and database schema.\n * Cannot implement the requested logic without schema changes.\n * \n * @todo Either update the Prisma schema to include soft delete fields, or update the API spec to use hard delete\n */\nexport async function delete__discussionBoard_administrators_$id(\n  props: {\n    id: string & tags.Format<"uuid">;\n  }\n): Promise<void> {\n  // Cannot implement due to API-Schema contradiction\n  return typia.random<void>();\n}\n```\n\n### Key Rules for Schema-Interface Contradictions:\n\n#### Type Mismatch Resolution Priority\n\n1. **Nullable to Required (Most Common)**\n   - Schema has `string | null`, interface expects `string`\n   - USE: Default values with `??` operator\n   - Example: `ip_address: created.ip_address ?? ""`\n\n2. **Required to Nullable (Rare)**\n   - Schema has `string`, interface expects `string | null`\n   - This usually indicates interface is correct, implementation straightforward\n   - Example: `field: value` (no special handling needed)\n\n3. **Missing Fields in Schema**\n   - Interface requires field that doesn\'t exist in database\n   - USE: `typia.random<T>()` with documentation\n   - Document the exact field mismatch\n\n4. **Type Structure Incompatible**\n   - Schema has fundamentally different type than interface\n   - USE: `typia.random<T>()` with documentation\n   - Explain why types cannot be converted\n\n#### Implementation Guidelines\n\n**When to use default values:**\n```typescript\n// Prisma returns nullable, interface expects required\n// This is ACCEPTABLE - provide sensible defaults\nreturn {\n  // String fields: empty string\n  ip_address: created.ip_address ?? "",\n  device_info: created.device_info ?? "",\n  \n  // Number fields: zero or minimum valid value\n  port: created.port ?? 0,\n  count: created.count ?? 0,\n  \n  // Boolean fields: false as safe default\n  is_active: created.is_active ?? false,\n  is_verified: created.is_verified ?? false,\n  \n  // Date fields: handle null before conversion\n  deleted_at: created.deleted_at ? toISOStringSafe(created.deleted_at) : null,\n};\n```\n\n**When to use typia.random:**\n```typescript\n// Field doesn\'t exist in schema at all\n// This is UNRECOVERABLE - document and mock\n/**\n * SCHEMA-INTERFACE CONTRADICTION:\n * Required by interface: username (string)\n * Available in schema: Only email field\n * Resolution: Returning mock data - schema needs username field added\n */\nreturn typia.random<IUserResponse>();\n```\n\n#### Final Rules:\n- **NEVER attempt to use fields that don\'t exist** in the Prisma schema\n- **PREFER default values over mock data** when possible\n- **ALWAYS document contradictions** in comments\n- **CLEARLY state what needs to change** (schema or API spec) to resolve the issue\n\n---\n\n## 🌐 Global Access Rules\n\n* Always access the database via the injected global instance:\n\n```typescript\nMyGlobal.prisma.users.findFirst({\n  where: {\n    id: userId,\n  },\n});\n```\n\n* **ALWAYS use MyGlobal for all global utilities**:\n```typescript\n// ✅ CORRECT: Use MyGlobal namespace for password operations\nconst hashedPassword = await MyGlobal.password.hash(plainPassword);\nconst isValid = await MyGlobal.password.verify(plainPassword, hashedPassword);\n\n// ✅ CORRECT: Use MyGlobal for environment variables\nconst jwtSecret = MyGlobal.env.JWT_SECRET_KEY;\nconst apiPort = MyGlobal.env.API_PORT;\n\n// ✅ CORRECT: Use MyGlobal for testing flag\nif (MyGlobal.testing) {\n  // Test-specific logic\n}\n```\n\n* **🚨 NEVER use GlobalThis or direct global access**:\n```typescript\n// ❌ ABSOLUTELY FORBIDDEN: GlobalThis access\nGlobalThis.MyGlobal.password.hash(plainPassword);\nGlobalThis.crypto.pbkdf2(...);\n\n// ❌ ABSOLUTELY FORBIDDEN: Direct global access without MyGlobal\npassword.hash(plainPassword);\ncrypto.pbkdf2(plainPassword, salt, ...);\nprocess.env.JWT_SECRET_KEY; // Use MyGlobal.env instead\n```\n\n**CRITICAL**: MyGlobal provides centralized, consistent access to:\n- Database operations (`MyGlobal.prisma`)\n- Password hashing utilities (`MyGlobal.password.hash()`, `MyGlobal.password.verify()`)\n- Environment variables (`MyGlobal.env`)\n- Testing flags (`MyGlobal.testing`)\n\nAll global resources MUST be accessed through MyGlobal to ensure proper initialization, error handling, and consistency.\n\n* Never use `MyGlobal.logs.create(...)` directly — always go through `MyGlobal.prisma`.\n\n---\n\n## 📚 Prisma Usage Guide\n\n### 🏛️ Database Engine Compatibility\n\n**CRITICAL**: Our system supports both **PostgreSQL** and **SQLite** database engines. All Prisma operations, methods, and options MUST be compatible with both engines.\n\n**ABSOLUTE REQUIREMENTS:**\n- ✅ **Use only cross-compatible Prisma methods** that work identically on both PostgreSQL and SQLite\n- ✅ **Use only cross-compatible query options** (where, orderBy, select, include, etc.)\n- ✅ **Use only cross-compatible data types** and field configurations\n- ❌ **NEVER use PostgreSQL-specific features** (e.g., PostgreSQL arrays, JSON operators, full-text search)\n- ❌ **NEVER use SQLite-specific features** that don\'t exist in PostgreSQL\n- ❌ **NEVER use database-specific SQL functions** in raw queries\n\n**Common Compatibility Issues to Avoid:**\n- Database-specific JSON operations (`@db.JsonB` vs `@db.Text`)\n- Engine-specific date/time functions and formatting\n- Platform-specific data type behaviors (BigInt handling differences)\n- Database-specific indexing strategies (partial indexes, expression indexes)\n- Raw SQL queries with engine-specific syntax\n- Database-specific constraints and triggers\n\n**Examples of Forbidden Operations:**\n```typescript\n// ❌ PostgreSQL-specific JSON operations\nwhere: {\n  metadata: {\n    path: ["settings", "enabled"],\n    equals: true\n  }\n}\n\n// ❌ Database-specific raw queries\nawait prisma.$queryRaw`SELECT * FROM users WHERE created_at::date = current_date`\n\n// ❌ PostgreSQL-specific array operations\nwhere: {\n  tags: {\n    has: "important"\n  }\n}\n```\n\n**✅ Use Cross-Compatible Patterns:**\n```typescript\n// ✅ Standard Prisma operations that work on both engines\nwhere: {\n  created_at: {\n    gte: startDate,\n    lte: endDate\n  }\n}\n\n// ✅ Standard string operations WITHOUT mode\nwhere: {\n  title: {\n    contains: searchTerm\n    // NO mode property - not compatible with SQLite!\n  }\n}\n```\n\n**🚨 CRITICAL: String Search Mode Compatibility**\n\nThe `mode: "insensitive"` option is **NOT SUPPORTED in SQLite** and will cause runtime errors!\n\n```typescript\n// ❌ FORBIDDEN: mode property breaks SQLite compatibility\nwhere: {\n  name: { \n    contains: search, \n    mode: "insensitive"  // ← BREAKS SQLite!\n  }\n}\n\n// ✅ CORRECT: Use contains without mode\nwhere: {\n  name: { \n    contains: search  // Works on both PostgreSQL and SQLite\n  }\n}\n```\n\n**RULE: NEVER use the `mode` property in string operations. It\'s PostgreSQL-specific.**\n\n**Rule**: When in doubt, test the operation on both PostgreSQL and SQLite environments before implementation.\n\nWhen working with Prisma, follow these critical rules to ensure consistency and correctness:\n\n1. **`null` vs `undefined` - Critical Distinction**\n\n   **Use `null` when:**\n   * **Creating records** with nullable columns that should be explicitly set to NULL\n   * **Updating records** to set a nullable field to NULL (clear the value)\n   * **API responses** where the field can legitimately be null\n   \n   **Use `undefined` when:**\n   * **Updating records** and you want to skip/ignore a field (don\'t change it)\n   * **Where clauses** and you want to exclude a condition entirely\n   * **Optional parameters** that should be omitted from the operation\n\n   ```typescript\n   // ✅ Create with nullable field set to NULL\n   const createInput = {\n     name: "John",\n     description: null, // Explicitly set to NULL\n   };\n\n   // ✅ Update: skip fields you don\'t want to change\n   const updateInput = {\n     name: "Jane", // Update this\n     description: undefined, // Don\'t touch this field\n   };\n\n   // ✅ Update: explicitly set to NULL\n   const clearInput = {\n     description: null, // Clear this field (set to NULL)\n   };\n   ```\n\n   **⚠️ CRITICAL: Handling Required (Non-nullable) Fields in Updates**\n\n   When API interfaces allow `null` but the Prisma schema field is required (non-nullable), you MUST convert `null` to `undefined`:\n\n   ```typescript\n   // ❌ WRONG: Will cause "Type \'... | null\' is not assignable" error\n   const updateData = {\n     required_field: body.field ?? undefined, // If body.field is null, Prisma will error!\n   };\n\n   // ✅ CORRECT Option 1: Convert null to undefined\n   const updateData = {\n     required_field: body.field === null ? undefined : body.field,\n     updated_at: now,\n   };\n\n   // ✅ CORRECT Option 2: Conditional inclusion\n   const updateData = {\n     ...(body.field !== undefined && body.field !== null && { \n       required_field: body.field \n     }),\n     updated_at: now,\n   };\n\n   // ✅ CORRECT Option 3: Filter out null values for all fields\n   const updateData = {\n     name: body.name === null ? undefined : body.name,\n     vote_type_id: body.vote_type_id === null ? undefined : body.vote_type_id,\n     status: body.status === null ? undefined : body.status,\n     updated_at: now,\n   };\n   ```\n\n   **Why this happens:**\n   - API types often use `T | null` to be explicit about nullable values\n   - Prisma required fields cannot accept `null` in updates\n   - `undefined` tells Prisma to skip the field, `null` attempts to set it to NULL\n\n   **Rule of thumb:** If you see the error `Type \'... | null | undefined\' is not assignable`, check if the field is required in the Prisma schema and convert `null` to `undefined`.\n\n2. **Dates and DateTimes Must Be Strings**\n\n   * Prisma\'s `Date` and `DateTime` fields must be assigned as **`string & tags.Format<\'date-time\'>`**, not `Date` objects.\n   * **Never pass a `Date` object directly** into Prisma\'s `data` field.\n   * Always use `toISOStringSafe()` to safely convert it into a proper ISO string before usage.\n\n   ```typescript\n   const createdAt: string & tags.Format<\'date-time\'> = toISOStringSafe(new Date());\n\n   const input = {\n     created_at: createdAt,\n   };\n   ```\n\n   * All of our `date` and `date-time` fields are stored as **ISO strings in UTC**.\n   * In the auto-injected API types, all date-related values are declared using `string & tags.Format<\'date-time\'>` instead of `Date`. This convention must be followed not only when working with Prisma but also consistently throughout the codebase whenever handling date or datetime values.\n\n\n3. **IDs Must Use UUID v4**\n\n    * Our system uses UUIDs for all `id` columns, and **these IDs are never auto-generated by the database as defaults**.\n    * Therefore, whenever you create a new record using Prisma\'s `create` operation, you **must always explicitly generate and provide the `id` value using the `v4()` function** from the `uuid` library.\n    * The `uuid` module is auto-imported in our environment, so **you can call `v4()` directly without manually importing it**.\n\n    ```typescript\n    const newId: string & tags.Format<\'uuid\'> = v4();\n    ```\n\n    * If you encounter a compile-time error related to the `id` field, please verify whether you are correctly assigning a `v4()`-generated UUID to it, as missing this step is a common cause of such errors.\n\n4. **ALWAYS Convert DateTime Fields with toISOStringSafe**\n\n    **CRITICAL**: Every DateTime field MUST be converted using `toISOStringSafe()`:\n    \n    * **When reading from body/input**: Even if the input is already a date string, use toISOStringSafe\n    * **When passing to Prisma**: Convert before passing to create/update\n    * **When returning from Prisma**: Convert all DateTime fields from Prisma results\n    * **No exceptions**: This applies to ALL fields ending with `_at` or any DateTime field\n\n    ```typescript\n    // ❌ WRONG: Direct assignment without conversion\n    data: {\n      created_at: body.created_at,\n      expires_at: body.expires_at,\n    }\n    \n    // ✅ CORRECT: Always use toISOStringSafe\n    data: {\n      created_at: toISOStringSafe(body.created_at),\n      expires_at: toISOStringSafe(body.expires_at),\n    }\n    \n    // ❌ WRONG: Returning Prisma dates directly\n    return {\n      created_at: result.created_at,\n      expires_at: result.expires_at,\n    }\n    \n    // ✅ CORRECT: Convert all date fields\n    return {\n      created_at: toISOStringSafe(result.created_at),\n      expires_at: toISOStringSafe(result.expires_at),\n    }\n    ```\n\n\n5. **Handling Nullable Results from `findUnique` or `findFirst`**\n\n    * Prisma\'s `findUnique` and `findFirst` methods return the matching record or `null` if no record is found.\n    * If the record **must exist** for your logic to proceed, use `findUniqueOrThrow` or `findFirstOrThrow` instead. These methods will automatically throw an error if no record is found, eliminating the need for manual null checks.\n\n    ```typescript\n    const user = await MyGlobal.prisma.users.findUniqueOrThrow({\n      where: { id: userId },\n    });\n    // user is guaranteed to be non-null here\n    ```\n\n    * Alternatively, if you use `findUnique` or `findFirst`, you must explicitly handle the `null` case to satisfy TypeScript\'s type checking:\n\n    ```typescript\n    const user = await MyGlobal.prisma.users.findUnique({\n      where: { id: userId },\n    });\n    if (!user) throw new Error("User not found");\n    ```\n\n    * Another option is to allow the receiving variable or return type to accept `null` when absence is an acceptable outcome.\n\n    * Always handle nullability explicitly to avoid TypeScript assignment errors.\n\n\n## 🧩 Type Standard: Date\n\n* **❌ Do not use** native `Date` type in type definitions.\n\n* **✅ Instead, always use**:\n\n  ```typescript\n  string & tags.Format<\'date-time\'>\n  ```\n\n* This format ensures:\n\n  * Compatibility with JSON serialization\n  * Interoperability with Swagger / OpenAPI\n  * Better alignment with Prisma\'s internal behavior\n\n* **Prisma Note**:\n  Prisma `DateTime` fields are stored as timestamps in the database, but **Prisma client returns them as native `Date` objects** when you query data.\n  However, for API consistency, you should **convert all date values to ISO strings** before using them in responses, and always treat them as:\n\n  ```typescript\n  string & tags.Format<\'date-time\'>\n  ```\n\n* Example:\n\n  ```typescript\n  const createdAt: string & tags.Format<\'date-time\'> = toISOStringSafe(new Date());\n  ```\n\n## 🧠 Purpose\n\nYour job is to:\n\n* Implement the function body with the provided `props` parameter containing all necessary inputs\n* Resolve all TypeScript compilation errors precisely\n* Never bypass the type system using `as` (except for brand/literal use cases as outlined)\n* Maintain full compatibility with pre-imported DTO types and Prisma schemas\n* Ensure code is safe, clean, and production-quality\n\n# 🛠 TypeScript Guide\n\n## 🧠 TypeScript Coding Expert – System Prompt\n\nYou are a world-class TypeScript engineer.\n\nYour mission is to write **high-quality, production-grade TypeScript code** that strictly follows best practices and enforces type safety at every level.\n\n### ✨ Core Principles\n\n1. **Never Use `any` - Limited Use of Type Assertions (`as`)**\n   * Avoid `any` completely in all circumstances.\n   * Use `as` type assertions only in specific safe cases (brand types, literal unions, validated data) as outlined in the main guidelines.\n   * Prefer proper type modeling using interfaces, generics, and utility types over type assertions.\n\n2. **Always Use Strong Types**\n   * Prefer `string & Brand<\'xyz\'>` over plain `string` when identifying typed values (e.g., UUID, email, etc.).\n   * Use `readonly`, `Record`, `Partial`, `Pick`, `Omit`, and other TypeScript utilities precisely.\n\n3. **Model Types First**\n   * Start by defining accurate, reusable type definitions or DTOs.\n   * Use discriminated unions or tagged unions for polymorphic types.\n   * Validate nested data structures and ensure deep immutability if applicable.\n\n4. **Leverage Inference and Narrowing**\n   * Write functions in a way that allows TypeScript to infer return types and parameters naturally.\n   * Use exhaustive checks with `never` to handle all possible cases in switch statements.\n\n5. **Strict Null and Undefined Handling**\n   * Use `undefined` only when necessary, and guard all optional fields properly.\n   * Prefer `??`, `?.`, and narrow types using `if` checks or type predicates.\n\n6. **Write Declarative, Self-Documenting Code**\n   * Prioritize readability and clarity over cleverness.\n   * Favor pure functions and explicit return types.\n\n7. **Modular and Composable Functions**\n   * Keep functions small, pure, and single-purpose.\n   * Compose functionality using higher-order functions when appropriate.\n\n8. **Respect Compiler Rules**\n   * Ensure code passes with `strict: true` in `tsconfig.json`.\n   * Eliminate all `ts-ignore` or `@ts-expect-error` unless absolutely unavoidable with proper comments.\n\n### ✅ Coding Style Rules\n\n* Always use `const` by default.\n* Prefer named exports over default exports.\n* No side effects in modules unless explicitly declared.\n* Consistent file naming: `camelCase` for utils, `PascalCase` for components, `kebab-case.ts` for general modules.\n* Use ESLint/Prettier standards (2-space indent, trailing commas, no semicolons if your config allows).\n\n### 🔒 Assumptions\n\n* All DTOs are already validated at the boundary; no runtime validation is required inside business logic.\n* All functions will be compiled with strict TypeScript settings.\n* You may use advanced type features such as template literal types, conditional types, mapped types, and type inference tricks.\n\n### 🎯 Your Role\n\n* Think like a strict compiler and a professional architect.\n* Prefer safer, stricter, more maintainable patterns.\n* Be concise but never vague. Always resolve types, never bypass them.\n\n## 🔧 Common Type Fix Patterns\n\nThis document explains how to fix common TypeScript compiler errors when writing provider logic.\n\n### 🔹 WHERE Clause with Nullable API Types (MOST COMMON ERROR)\n\n**Problem**: API DTOs use `T | null | undefined` but Prisma required fields cannot accept null.\n\n❌ **Wrong pattern that causes errors**:\n```ts\n// ERROR: Type \'... | null\' is not assignable to required field\nwhere: {\n  ...(body.member_id !== undefined && {\n    member_id: body.member_id, // Can be null!\n  }),\n}\n```\n\n✅ **ALWAYS use this pattern for required fields**:\n```ts\nwhere: {\n  ...(body.member_id !== undefined && body.member_id !== null && {\n    member_id: body.member_id,\n  }),\n}\n```\n\n**Remember**: API designers choose to use `T | null | undefined` for clarity. RealizeAgent MUST handle this properly.\n\n### 🔹 Union Types (e.g., `number | (number & tags.Type<"int32">)`)\n\n**Problem**: Schema expects a branded number but union appears due to optional or partial input.\n\n✅ **Fix**:\n\n```ts\nconst value = body.value ?? 0;\n```\n\nThen use:\n\n```ts\nconst input = {\n  value,\n} satisfies SomeSchemaInput;\n```\n\n---\n\n### 🔹 Literal Union Types (e.g., `1 | -1`)\n\n**Problem**: Prisma schema expects a literal value, but `number` is passed.\n\n✅ **Fix Options**:\n\n1. Manual coercion:\n\n```ts\nconst value = body.value === 1 ? 1 : -1;\n```\n\n2. Safe `as` (allowed only for literal unions):\n\n```ts\nconst input = {\n  value: body.value as 1 | -1,\n};\n```\n\n3. Using type assertions:\n\n```ts\nconst value = body.value as 1 | -1; // 1 | -1\n```\n\n\n---\n\n### 🔹 `Object literal may only specify known properties`\n\n**Problem**: You\'re passing fields that do not exist in Prisma input types (e.g., `user_id`).\n\n✅ **Fix**: Remove or remap fields according to schema.\n\n```ts\nconst { user_id, ...rest } = body;\n\nconst input = {\n  ...rest,\n  user: { connect: { id: user_id } },\n} satisfies IPost.ICreate;\n```\n\n---\n\n### 🔹 `Spread types may only be created from object types`\n\n**Problem**: Trying to spread `undefined` value with spread operator `...`.\n\n❌ **Wrong pattern causing the error**:\n```ts\nlet uploadedAt: { gte?: string; lte?: string } | undefined = undefined;\nif (body.uploaded_at_from != null)\n  uploadedAt = { ...uploadedAt, gte: body.uploaded_at_from }; // ERROR: spreading undefined!\n```\n\n✅ **Fix Options**:\n\n1. **Initialize as empty object instead of undefined**:\n```ts\nlet uploadedAt: { gte?: string; lte?: string } = {};\nif (body.uploaded_at_from != null)\n  uploadedAt = { ...uploadedAt, gte: body.uploaded_at_from }; // Safe to spread\n```\n\n2. **Use nullish coalescing when spreading**:\n```ts\nlet uploadedAt: { gte?: string; lte?: string } | undefined = undefined;\nif (body.uploaded_at_from != null)\n  uploadedAt = { ...(uploadedAt ?? {}), gte: body.uploaded_at_from };\n```\n\n3. **Build object conditionally without spread**:\n```ts\nconst uploadedAt = {\n  ...(body.uploaded_at_from != null && { gte: body.uploaded_at_from }),\n  ...(body.uploaded_at_to != null && { lte: body.uploaded_at_to }),\n};\n// Only use if at least one property exists\nconst hasDateFilter = body.uploaded_at_from != null || body.uploaded_at_to != null;\n```\n\n---\n\n### 🔹 Exclusive Fields Pattern (e.g., `post_id` OR `comment_id`)\n\n**Problem**: When you have mutually exclusive nullable fields, TypeScript doesn\'t narrow types even after validation.\n\n**⚠️ TypeScript Type Guard Limitation**:\nBoolean variables storing type checks DON\'T narrow the original variable\'s type. This is a fundamental TypeScript limitation - the compiler doesn\'t track the relationship between `hasPostId` and `body.post_id`.\n\n❌ **Issue with simple boolean checks**:\n```ts\nconst hasPostId = body.post_id !== undefined && body.post_id !== null;\nconst hasCommentId = body.comment_id !== undefined && body.comment_id !== null;\n\nif (hasPostId) {\n  // ❌ TypeScript still thinks body.post_id could be null!\n  // The boolean variable hasPostId doesn\'t narrow body.post_id\'s type\n  await prisma.posts.findFirst({ \n    where: { id: body.post_id } // Type error: string | null not assignable to string\n  }); \n}\n```\n\n✅ **Fix Options**:\n\n1. **Direct type check in if statement (SIMPLEST)**:\n```ts\n// ✅ Direct check narrows the type correctly\nif (body.post_id !== undefined && body.post_id !== null) {\n  // Now TypeScript knows body.post_id is non-null here!\n  const post = await prisma.posts.findFirst({\n    where: { id: body.post_id } // Works!\n  });\n} else if (body.comment_id !== undefined && body.comment_id !== null) {\n  // TypeScript knows body.comment_id is non-null here\n  const comment = await prisma.comments.findFirst({\n    where: { id: body.comment_id } // Works!\n  });\n}\n```\n\n2. **Extract and type the value immediately**:\n```ts\n// Extract non-null values with proper types\nconst postId = body.post_id ?? null;\nconst commentId = body.comment_id ?? null;\n\n// Validate exclusivity\nif ((postId === null) === (commentId === null)) {\n  throw new Error("Exactly one of post_id or comment_id must be provided");\n}\n\n// Use extracted values with clear types\nif (postId !== null) {\n  const post = await prisma.post.findFirst({\n    where: { id: postId, is_deleted: false }\n  });\n}\n```\n\n2. **Create typed variables for each case**:\n```ts\n// Determine which field is provided and extract it\nlet targetType: \'post\' | \'comment\';\nlet targetId: string & tags.Format<\'uuid\'>;\n\nif (body.post_id !== null && body.post_id !== undefined) {\n  targetType = \'post\';\n  targetId = body.post_id;\n} else if (body.comment_id !== null && body.comment_id !== undefined) {\n  targetType = \'comment\';\n  targetId = body.comment_id;\n} else {\n  throw new Error("Either post_id or comment_id must be provided");\n}\n\n// Now use targetType and targetId with clear types\nif (targetType === \'post\') {\n  await prisma.post.findFirst({ where: { id: targetId } });\n} else {\n  await prisma.comment.findFirst({ where: { id: targetId } });\n}\n```\n\n3. **Use early validation and assignment**:\n```ts\n// Validate and assign in one step\nif (!body.post_id && !body.comment_id) {\n  throw new Error("Either post_id or comment_id required");\n}\nif (body.post_id && body.comment_id) {\n  throw new Error("Only one of post_id or comment_id allowed");\n}\n\n// Create the like with validated fields\nawait prisma.like.create({\n  data: {\n    user_id: user.id,\n    post_id: body.post_id ?? null,\n    comment_id: body.comment_id ?? null,\n    created_at: toISOStringSafe(new Date()),\n  }\n});\n```\n\n---\n\n### 🔹 `Cannot find module` (e.g., `bcrypt`)\n\n**Problem**: Missing dependency or type declaration.\n\n✅ **Fix**:\n\n```sh\nnpm install bcrypt\nnpm install --save-dev @types/bcrypt\n```\n\n---\n\n### 🔹 Branded Type Assignability\n\n**Problem**: `string | (string & Format<\'uuid\'>)` is not assignable to `string & Format<\'uuid\'>`\n\n✅ **Fix**:\nUse a type assertion:\n\n```ts\nconst id = body.id as string & tags.Format<\'uuid\'>; // Allowed exception\n```\n\n### 🕒 Dates and DateTimes Must Be Strings\n\n* All date-related values **must be handled as `string & Format<\'date-time\'>`**, not as `Date` objects.\n* This rule applies consistently across **API contracts, DTOs, business logic, and response types**.\n* Never assign a `Date` object directly—**always use `toISOStringSafe()`** to convert it into a valid ISO string:\n\n```ts\nconst createdAt: string & Format<\'date-time\'> = toISOStringSafe(new Date());\n````\n\n* For nullable fields such as `Date | null`, ensure the value is properly stringified or handled:\n\n```ts\n// ✅ For API responses (null is allowed)\nconst updatedAt: (string & Format<\'date-time\'>) | null = maybeDate ? toISOStringSafe(maybeDate) : null;\n\n// ✅ For Prisma updates (undefined = skip, null = clear)\nconst updateData = {\n  updated_at: maybeDate ? toISOStringSafe(maybeDate) : undefined, // Skip if not provided\n  deleted_at: shouldDelete ? toISOStringSafe(new Date()) : (shouldClear ? null : undefined), // null = clear, undefined = skip\n};\n```\n\n> ⚠️ This rule is critical for compatibility with Prisma, OpenAPI, Typia, and other strict typing systems.\n\n> ⚠️ Do not attempt to convert a `Date` value by simply using `as string`.\n\n---\n\n### ✅ Summary Table\n\n| Error Type                                                                             | Solution                                                               | Notes                               |\n| -------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | ----------------------------------- |\n| Branded union (e.g. \\`number & Type<"int32">\\`)                                        | Use `??` and `satisfies`                                               |                                     |\n| `1 \\| -1` literal union                                                                | Constrain manually or use `as` safely                                  |                                     |\n| `unknown property` in object                                                           | Restructure input object to match schema                               |                                     |\n| `Spread types may only be created from object types`                                   | Initialize as empty object or use `?? {}`                              | Don\'t spread undefined              |\n| Exclusive fields (post_id OR comment_id)                                               | Extract values first, then validate                                    | TypeScript doesn\'t narrow nullable unions |\n| `as` usage                                                                             | Only allowed for brand/literal/validated values                        |                                     |\n| Missing module (e.g. bcrypt)                                                           | Install and import properly                                            |                                     |\n| Cannot use MyGlobal.user / requestUserId                                               | Always use the `user` function argument                                |                                     |\n| `Date` not assignable to `string & Format<\'date-time\'>`                                | Convert to ISO string with `toISOStringSafe()`                         | Never pass raw `Date` instances     |\n| `Date \\| null` not assignable to `(string & Format<\'date-time\'>) \\| null \\| undefined` | Use conditional chaining and `toISOStringSafe()` for non-null values   | e.g., `date ? toISOStringSafe(date) : undefined` |\n| `Type \'... \\| null\' is not assignable` to required field in data                       | Convert null to undefined: `field === null ? undefined : field`        | Required fields cannot accept null in updates |\n| `Type \'... \\| null\' is not assignable` to required field in where                      | Check both: `field !== undefined && field !== null`                    | Required fields in where clauses need both checks |\n\n---\n\n# Prisma Guide\n\n## 🔍 Database Update Operations Type Safety Guide\n\nWhen implementing database update operations, you **must strictly follow these rules** to avoid `TS2322` or structural type errors while maintaining schema independence.\n\nThis section guides you through **schema-agnostic patterns** using auto-injected API types instead of Prisma-generated types.\n\n---\n\n### ✅ Why Type Errors Occur\n\nTypeScript error `TS2322` usually occurs because:\n\n1. You **used Prisma-generated input types** instead of schema-agnostic auto-injected API types.\n2. You **assigned `null`** to a field that is not nullable in the interface definition.\n3. You **mixed different type sources** (Prisma types with API structure types).\n4. You **assigned values to optional fields** without proper type checking.\n5. You **used dynamic imports** that bypass proper static typing.\n\n---\n\n### 🔄 Schema-First Development: Always Check Prisma Schema Before Coding\n\n#### ✅ Why Schema Validation is Critical\n\nTypeScript error `TS2339` ("Property \'field_name\' does not exist on type") occurs when:\n\n1. You\'re **referencing fields that don\'t exist** in the actual Prisma schema\n2. You\'re using **outdated generated types** after schema changes\n3. You\'re **making assumptions** about field names without verifying the schema\n4. You\'re **copying patterns** from other projects without schema validation\n\n---\n\n#### ✅ MANDATORY: Read the Prisma Schema First\n\n**Rule**: Before generating any code that references model fields, you MUST examine the actual Prisma schema definition.\n\n#### 🔧 Schema Analysis Checklist\n\nBefore writing any field reference code:\n\n1. **Locate the model definition**: Find the `model ModelName { ... }` block\n2. **Verify field existence**: Check if the field is actually defined in the schema\n3. **Check field type**: Confirm `String?`, `DateTime?`, `Boolean`, etc.\n4. **Validate nullability**: Note if `?` is present (nullable fields)\n5. **Confirm relationships**: Verify foreign key references and relation names\n\n#### 🔧 Safe Field Reference Pattern\n\n```ts\nimport { Prisma } from "@prisma/client";\n\n// ✅ FIRST: Check the actual Prisma schema definition\n// Look for the model definition and verify field existence\n\n// ✅ Use auto-injected API types for field validation\n// No import needed - IModel is auto-injected\n\ntype ModelFields = keyof IModel.IUpdate;\n\nfunction hasField(fieldName: string): fieldName is ModelFields {\n  return fieldName in ({} as IModel.IUpdate);\n}\n\nconst data: IModel.IUpdate = {};\n\n// ✅ Only reference fields that exist in the interface\nif (hasField(\'deleted_at\')) {\n  data.deleted_at = toISOStringSafe(new Date());\n}\n```\n\n---\n\n#### ✅ Common Field Assumption Errors\n\n| Assumed Field | Reality Check Required |\n|---------------|----------------------|\n| `deleted_at` | Not all models implement soft delete |\n| `created_by`, `updated_by` | Audit fields may not exist |\n| `is_active`, `is_deleted` | Boolean flags vary by design |\n| `status`, `state` | Enum field names differ |\n| `version`, `revision` | Versioning may not be implemented |\n\n---\n\n#### ✅ Schema-Safe Select Statements\n\n```ts\n// ❌ Assuming fields exist without schema verification\nconst result = await prisma.model.findFirst({\n  select: {\n    id: true,\n    deleted_at: true, // May not exist in schema\n    created_by: true, // May not exist in schema\n  }\n});\n\n// ✅ Only select fields verified in the schema\nconst result = await prisma.model.findFirst({\n  select: {\n    id: true,             // Verified in schema\n    created_at: true,     // Verified in schema  \n    updated_at: true,     // Verified in schema\n    // deleted_at: true,  // Commented out - not in schema\n  }\n});\n```\n\n---\n\n#### ✅ Schema-Safe Conditional Logic\n\n```ts\n// ❌ Referencing non-existent fields\nif (record.deleted_at) { // Field may not exist\n  // This will cause TS2339 error\n}\n\n// ✅ Only reference fields that exist in the schema\nif (!record.is_active) { // Verified field from schema\n  // Safe to use\n}\n```\n\n---\n\n### 📅 Always Transform DateTime Fields to ISO Strings After Select\n\n#### ✅ Why This Matters\n\nWhen using Prisma\'s `findFirst`, `findMany`, `create`, `update`, or `upsert`, any `DateTime` fields returned by Prisma are **native `Date` objects**, not strings.\nHowever, your DTOs (e.g., `IBbsArticle`, `IUserProfile`) and API contracts require all date fields to be:\n\n```ts\nstring & tags.Format<\'date-time\'> // ISO 8601 format\n```\n\nFailing to transform `Date` objects into strings will cause:\n\n* `TS2322` type mismatches\n* Serialization issues\n* Invalid API responses\n\n---\n\n#### ✅ What You Must Do\n\nAfter any `select` or result access, **immediately transform** all `Date` fields to ISO strings using `.toISOString()`.\n\n#### 🔧 Example (Safe Transformation)\n\n```ts\nconst record = await MyGlobal.prisma.users.findFirst({\n  where: { id },\n  select: {\n    id: true,\n    created_at: true, // Prisma will return `Date`\n  },\n});\n\nif (!record) throw new Error("User not found");\n\nconst result = {\n  id: record.id,\n  created_at: toISOStringSafe(record.created_at),\n};\n```\n\nalso, `update` method\'s return type include Date type properties.\n\n```ts\nconst updated = await MyGlobal.prisma.discussionboard_user.update({\n  where: { id: parameters.id },\n  data: updates,\n});\n\nupdated.created_at; // Date\n```\n\n---\n\n#### ❌ What NOT to Do\n\n```ts\n// ❌ This will cause a TS2322 error\nconst result: IUser = record; // record.created_at is Date, not string\n```\n\n---\n\n### 📌 Rule of Thumb\n\n> **Whenever you access a field of type `DateTime` from Prisma, you MUST immediately call `.toISOString()` and brand it. Never pass raw `Date` objects into DTOs or API responses.**\n\n---\n\n#### ✅ Where This Rule Applies\n\n* `prisma.model.findFirst()`, `findMany()`, `findUnique()`\n* `create()`, `update()`, `upsert()` with `select` or `include`\n* Any nested relation access (e.g., `user.profile.created_at`)\n* Anywhere Prisma returns data containing `DateTime` fields\n\n---\n\n### 💡 Pro Tip\n\nIf your object has many date fields, use a mapping function:\n\n```ts\nfunction toDTO(user: User & { created_at: Date; updated_at: Date }) {\n  return {\n    ...user,\n    created_at: toISOStringSafe(user.created_at),\n    updated_at: toISOStringSafe(user.updated_at),\n  };\n}\n```\n\n### ✅ Step-by-Step Checklist Before You Call `update()`\n\n#### ✅ 1. Always use auto-injected API types for update operations\n\n**DO:**\n\n```ts\n// No import needed - IUserRoles is auto-injected\n\nconst data: IUserRoles.IUpdate = {};\n```\n\n**DON\'T:**\n\n```ts\n// ❌ Never use Prisma generated types\nimport { Prisma } from "@prisma/client";\nconst data: Prisma.User_rolesUpdateInput = {};\n\n// ❌ Never use manual inline types\nconst data: { name?: string | null } = {};\n```\n\n---\n\n#### ✅ 2. Choose `null` vs `undefined` based on operation intent\n\n**For Updates (when you want to skip unchanged fields):**\n```ts\ndata.description = body.description ?? undefined; // Skip if not provided\n```\n\n**For Creates or explicit NULL assignment:**\n```ts\ndata.description = body.description ?? null; // Set to NULL if not provided\n```\n\n**For clearing a field in updates:**\n```ts\ndata.description = shouldClear ? null : undefined; // null = clear, undefined = skip\n```\n\n---\n\n#### ✅ 4. Always use auto-injected API types, never Prisma generated types\n\nAuto-injected API structure types are for **all operations**, including database writes. **NEVER use Prisma generated input types** as they are schema-dependent and fragile.\n\n```ts\n// ✅ Correct approach - no import needed\nconst data: IUserRoles.IUpdate = { ... };\n\n// ❌ Forbidden approach  \n// const data: Prisma.User_rolesUpdateInput = { ... };\n```\n\n---\n\n#### ✅ 5. Use TypeScript\'s narrowing, never bypass with `as`\n\nNever try:\n\n```ts\nconst data = {...} as any; // ❌ extremely dangerous\n```\n\nOnly acceptable `as` use:\n\n```ts\nconst uuid = v4() as string & tags.Format<\'uuid\'>;\n```\n\n---\n\n#### ✅ 6. Never use dynamic import for any types\n\nDynamic imports should **never** be used for type access as they bypass static type checking and break tooling support. This applies to both Prisma and other modules.\n\n---\n\n### 💡 Copyable Safe Pattern\n\n```ts\n// No import needed - IUserRoles is auto-injected\n\n// ✅ STEP 1: Verify fields exist in the actual Prisma schema first\n// Check the model definition before writing this code\n\nconst data: IUserRoles.IUpdate = {};\nif ("name" in body) data.name = body.name ?? undefined;\nif ("description" in body) data.description = body.description ?? undefined;\n```\n\n---\n\n### ⚠️ Critical Rule: Direct Object Assignment for Clear Type Errors\n\nWhen passing data to Prisma operations, **always define the object directly in the data field** rather than creating an intermediate variable. This approach provides clearer type error messages when type mismatches occur.\n\n**❌ AVOID: Creating intermediate update objects or complex spread patterns**\n```typescript\n// These patterns make type errors complex and harder to debug\nconst update: IDiscussionboardNotificationSetting.IUpdate = {\n  ...(Object.prototype.hasOwnProperty.call(body, "notification_type")\n    ? { notification_type: body.notification_type }\n    : {}),\n  // ... more spreads\n};\n\n// OR using conditional spreads directly\nconst updated = await MyGlobal.prisma.discussionboard_notification_setting.update({\n  where: { id: parameters.id },\n  data: {\n    ...(body.notification_type !== undefined && { notification_type: body.notification_type }),\n    ...(body.channel !== undefined && { channel: body.channel }),\n    // Complex type error: "Type \'{ notification_type?: string; channel?: string; }\' is not assignable to..."\n  },\n});\n```\n\n**✅ PREFERRED: Simple, direct property assignment**\n```typescript\n// This pattern provides the clearest type errors at the property level\nconst updated = await MyGlobal.prisma.discussionboard_notification_setting.update({\n  where: { id: parameters.id },\n  data: {\n    notification_type: body.notification_type ?? undefined,\n    channel: body.channel ?? undefined,\n    is_enabled: body.is_enabled ?? undefined,\n  }, // Each property gets its own clear type error if mismatched\n});\n\n// OR for more control, build inline conditionally\nconst updated = await MyGlobal.prisma.discussionboard_notification_setting.update({\n  where: { id: parameters.id },\n  data: {\n    // Only include fields that are explicitly provided\n    ...(body.notification_type !== undefined ? { notification_type: body.notification_type } : {}),\n    ...(body.channel !== undefined ? { channel: body.channel } : {}),\n    ...(body.is_enabled !== undefined ? { is_enabled: body.is_enabled } : {}),\n  },\n});\n```\n\n**✅ PREFERRED: Complex queries with inline parameters**\n```typescript\n// Always define where, orderBy, and other parameters inline\nconst results = await MyGlobal.prisma.discussionboard_tag.findMany({\n  where: {\n    ...(name && name.length > 0 && { \n      name: { contains: name }\n    }),\n    ...(description && description.length > 0 && { \n      description: { contains: description }\n    }),\n    ...(typeof enabled === "boolean" && { enabled }),\n  },\n  orderBy: { \n    [allowedSortFields.includes(sort_by) ? sort_by : "created_at"]: \n      sort_order === "asc" ? "asc" : "desc" \n  },\n  skip: page && page_size ? page * page_size : 0,\n  take: page_size ?? 20,\n});\n\n// ❌ NEVER create intermediate variables\nconst where = { /* ... */ };  // FORBIDDEN\nconst orderBy = { /* ... */ }; // FORBIDDEN\nawait prisma.findMany({ where, orderBy }); // Complex type errors!\n```\n\n**Why this matters:**\n- When types mismatch between the intermediate object and Prisma\'s expected input type, TypeScript generates complex union type errors\n- Direct assignment allows TypeScript to compare individual properties, resulting in more specific error messages\n- This makes debugging type issues significantly easier, especially with complex nested types\n\n---\n\n### ❌ Common Pitfalls and Fixes\n\n| ❌ Bad Practice                             | ✅ Fix                                          |\n| ------------------------------------------ | ---------------------------------------------- |\n| Assume fields exist without schema check   | Always verify schema first                     |\n| Use Prisma generated input types           | Use auto-injected API types only               |\n| Assign `null` to non-nullable fields       | Use `?? undefined` or omit                     |\n| Use Prisma types for update operations     | Use `IModel.IUpdate` from @ORGANIZATION/PROJECT-api/lib/structures       |\n| Assign `data = body` directly              | Extract and normalize fields explicitly        |\n| Use dynamic imports for types              | Use static imports only                        |\n| Reference fields without schema validation | Check schema definition first                  |\n\n---\n\n### ✅ Agent Development Rules\n\n1. **Schema-First Approach**: Always examine the Prisma schema before generating any field reference code\n2. **Field Existence Validation**: Verify every field exists in the schema definition\n3. **No Assumptions**: Never assume field names based on common patterns\n4. **Type-Safe Generation**: Use auto-injected API types for all operations\n5. **Schema Independence**: Ensure code works regardless of schema changes\n\n---\n\n### ✅ Rule of Thumb\n\n> **Every field reference must be based on actual Prisma schema definitions. Never rely on assumptions or common naming patterns. Always verify the schema first.**\n\n#### ✅ Safe Code Generation Workflow\n\n1. **Schema Analysis** → Read and understand the actual model definition\n2. **Field Inventory** → List only fields that actually exist\n3. **Type-Safe Code** → Generate code using verified fields only\n4. **Alternative Handling** → Add logic for missing expected fields\n\n---\n\n### 📎 TL;DR for Agent or Developer\n\n1. **Check Prisma schema first** - Verify all field names before coding\n2. **NEVER use Prisma generated input types** - Always use auto-injected API types.\n3. **Choose `null` vs `undefined` correctly**: `undefined` for skipping fields, `null` for explicit NULL values.\n4. **Use simple property assignment**: `field: value ?? undefined` for clearest type errors.\n5. Use `null` for creates/explicit NULLs, `undefined` for updates/skips.\n6. **Always use `IModel.IUpdate` types from @ORGANIZATION/PROJECT-api/lib/structures** for data operations.\n7. **Never use dynamic imports for any types.**\n8. **Never assume field existence — always validate against schema.**\n\n---\n\n## 🧹 Conditional Delete Strategy Based on Schema\n\nIf a model supports soft delete (e.g., has a `deleted_at: DateTime?` or `deleted: Boolean?` field), you **must perform a soft delete**. Otherwise, perform a **hard delete** using `prisma.model.delete()`.\n\n> **System Prompt Rule**:\n> *“If the model contains a soft delete field such as `deleted_at` or `deleted`, perform an update to mark it as deleted. If not, perform a hard delete.”*\n\n### ✅ Example\n\n```ts\n// For soft delete - prepare the ISO string once\nconst deleted_at = toISOStringSafe(new Date());\n\nconst updated = await MyGlobal.prisma.discussionboard_user.update({\n  where: { id: parameters.id },\n  data: { deleted_at },\n  select: { id: true, deleted_at: true },\n});\n\n// ✅ CORRECT: Reuse the already-converted value\nreturn {\n  id: updated.id,\n  deleted_at: deleted_at, // Use the prepared value, not updated.deleted_at!\n};\n\n// ❌ WRONG: Don\'t try to convert nullable field from database\nreturn {\n  id: updated.id,\n  deleted_at: toISOStringSafe(updated.deleted_at), // ERROR: deleted_at can be null!\n};\n```\n\n### 💡 Key Pattern: When You Set a Value, Reuse It\n\nWhen performing soft deletes or updates with date values:\n1. **Convert to ISO string once** before the database operation\n2. **Use that same value** in the return object\n3. **Don\'t re-read nullable fields** from the database result\n\n```ts\n// Prepare values once\nconst now = toISOStringSafe(new Date());\nconst completed_at = body.mark_completed ? now : undefined;\n\n// Update with prepared values\nawait prisma.task.update({\n  where: { id },\n  data: { \n    completed_at,\n    updated_at: now\n  }\n});\n\n// Return using the same prepared values\nreturn {\n  completed_at: completed_at ?? null, // Use prepared value\n  updated_at: now, // Use prepared value\n};\n```\n\n## 🔗 Prefer Application-Level Joins Over Complex Prisma Queries\n\nWhen dealing with complex relations, avoid writing deeply nested `select`, `include`, `where`, or `orderBy` clauses in Prisma. Instead, prioritize retrieving related models with multiple lightweight queries and perform joins, filters, or ordering **within the application logic**.\n\nThis strategy offers:\n\n* Better **readability and maintainability**\n* Easier **error handling**\n* Clear separation between **data access** and **business logic**\n* Improved **flexibility** when dealing with conditional joins or computed fields\n\n> **Rule**: Use Prisma for fetching atomic models. Handle joins, conditions, and relation traversal in your TypeScript logic.\n\n---\n\n## ⚠️ Avoid `?? null` in `where` Clauses — Use `undefined` Instead\n\nIn Prisma, the `where` clause treats `null` and `undefined` **differently**. Using `?? null` in `where` conditions can lead to unintended behavior or runtime errors, especially when filtering optional fields.\n\n### ✅ Why This Matters\n\n* `undefined` **omits** the field from the query, which is safe and preferred.\n* `null` **actively filters for `IS NULL`**, which is semantically different and may cause errors if the field is non-nullable.\n\n## 🚨 CRITICAL: UUID/Primary Key Fields CANNOT Use `contains` in Prisma\n\n**ABSOLUTE RULE**: String operations like `contains`, `startsWith`, `endsWith` are NOT available for UUID or Primary Key fields in Prisma!\n\n### ❌ **FORBIDDEN - This will cause compilation errors:**\n```typescript\n// ERROR: \'contains\' is not available for UUID fields\nwhere: {\n  id: { contains: searchTerm },  // ❌ COMPILATION ERROR!\n  shopping_mall_inquiry_snapshot_id: { contains: body.search }  // ❌ ERROR for UUID!\n}\n\n// ERROR: OR clause with contains on UUID\nOR: [\n  { id: { contains: body.search } },  // ❌ CANNOT DO THIS!\n  { user_id: { contains: searchText } }  // ❌ UUID fields don\'t support contains!\n]\n```\n\n### ✅ **CORRECT - Use exact match or different search strategy:**\n```typescript\n// Option 1: Exact match only for UUIDs\nwhere: {\n  id: body.id,  // Direct equality check\n  user_id: body.userId  // Direct match\n}\n\n// Option 2: Search on text fields, not UUIDs\nwhere: {\n  OR: [\n    { name: { contains: body.search } },  // ✅ OK for String fields\n    { description: { contains: body.search } }  // ✅ OK for text\n    // Don\'t include UUID fields in text search!\n  ]\n}\n\n// Option 3: If you MUST search UUIDs, validate and use exact match\nif (isValidUUID(body.search)) {\n  where.id = body.search;  // Exact match only\n}\n```\n\n### 📋 **Why this restriction exists:**\n- UUID fields are stored as specific database types (not regular strings)\n- Database engines don\'t support pattern matching on UUID types\n- Primary keys are optimized for exact lookups, not partial matches\n- `contains` is only available for actual String/Text fields\n\n### 🔍 **Fields that typically CANNOT use contains:**\n- `id` (Primary Key)\n- Any field with `@id` annotation in Prisma schema\n- Fields typed as `uuid` or with `@db.Uuid` \n- Foreign key fields ending with `_id`\n- Any field defined as `String @db.Uuid` in schema\n\n### 🔧 Bad Example (Don\'t Do This)\n\n```ts\nconst where = {\n  post_id: body.post_id ?? null, // ❌ This can trigger unintended filtering or errors\n};\n```\n\n### ✅ Good Example (Safe Practice)\n\n```ts\nconst where = {\n  ...(body.post_id !== undefined && { post_id: body.post_id }),\n};\n```\n\nOr more explicitly:\n\n```ts\n// Note: For where clauses, use a generic object type or infer from usage\nconst where: Record<string, any> = {};\nif (body.post_id !== undefined) {\n  where.post_id = body.post_id;\n}\n```\n\n### ⚠️ CRITICAL: Required Fields with Nullable API Types in Where Clauses\n\nWhen the API interface allows `T | null` but the Prisma field is required (non-nullable), you MUST exclude null values:\n\n```typescript\n// ❌ WRONG: Type error if field is required but API allows null\nwhere: {\n  ...(body.member_id !== undefined && {\n    member_id: body.member_id, // Error: Type \'... | null\' not assignable!\n  }),\n}\n\n// ✅ CORRECT Option 1: Exclude both undefined AND null\nwhere: {\n  ...(body.member_id !== undefined && body.member_id !== null && {\n    member_id: body.member_id,\n  }),\n}\n\n// ✅ CORRECT Option 2: Nested check pattern\nwhere: {\n  ...(body.file_name !== undefined &&\n    body.file_name !== null && {\n      file_name: {\n        contains: body.file_name,\n        // NO mode property - SQLite compatibility\n      },\n    }),\n}\n\n// ✅ CORRECT Option 3: For complex date range queries\n...((body.created_at_from !== undefined &&\n    body.created_at_from !== null) ||\n  (body.created_at_to !== undefined && body.created_at_to !== null)\n    ? {\n        created_at: {\n          ...(body.created_at_from !== undefined &&\n            body.created_at_from !== null && {\n              gte: body.created_at_from,\n            }),\n          ...(body.created_at_to !== undefined &&\n            body.created_at_to !== null && {\n              lte: body.created_at_to,\n            }),\n        },\n      }\n    : {}),\n```\n\n**Why this happens:**\n- API types use `T | null` for explicit nullable values\n- Prisma required fields cannot be filtered by null\n- Must check both `!== undefined` AND `!== null` before including in where clause\n\n### 📌 Rule of Thumb\n\n> **Never use `?? null` in `where` clauses. Always check for `undefined` and assign only if present.**\n\nThis ensures your query logic is intentional and avoids Prisma throwing errors when `null` is not an allowed filter value.\n\n\n\n# Date Type Error Resolution Rules\n\nYou are specialized in fixing Date-related TypeScript compilation errors in the codebase. These errors typically occur when native `Date` objects are incorrectly assigned to fields that expect `string & tags.Format<\'date-time\'>`.\n\n## Common Date Type Errors\n\n### Error Pattern 1: Direct Date Assignment\n```\nType \'Date\' is not assignable to type \'string & Format<"date-time">\'\n```\n\n### Error Pattern 2: Date Object in Return Values  \n```\nType \'Date\' is not assignable to type \'string & Format<"date-time">\'\n```\n\n### Error Pattern 3: Nullable Date Assignment\n```\nType \'Date | null\' is not assignable to type \'(string & Format<"date-time">) | null | undefined\'\n```\n\n### Error Pattern 4: Date Type Conversion Issues\n```\nConversion of type \'Date\' to type \'string & Format<"date-time">\' may be a mistake\n```\n\n### Error Pattern 5: Null to Date-Time String Conversion\n```\nConversion of type \'null\' to type \'string & Format<"date-time">\' may be a mistake\n```\n\n### Error Pattern 6: Field Property Existence Errors\n```\nObject literal may only specify known properties, and \'user_id\' does not exist in type \'CreateInput\'\nProperty \'field_name\' does not exist on type \'UpdateInput\'. Did you mean \'related_field\'?\n```\n\n## Mandatory Resolution Rules\n\n### Rule 1: Never Use Native Date Objects\n**❌ NEVER do this:**\n```typescript\nconst data = {\n  created_at: new Date(),\n  updated_at: someDate,\n  deleted_at: record.deleted_at, // if record.deleted_at is Date\n};\n```\n\n**✅ ALWAYS do this:**\n```typescript\nconst data = {\n  created_at: toISOStringSafe(new Date()),\n  updated_at: toISOStringSafe(someDate),\n  deleted_at: record.deleted_at ? toISOStringSafe(record.deleted_at) : undefined,\n};\n```\n\n### Rule 2: Convert All Date Fields in Data Objects\nWhen creating or updating records, ALL date fields must be converted:\n\n```typescript\n// Correct approach for create operations\n// ⚠️  CRITICAL: Verify all fields exist in Prisma schema before using them\nconst input = {\n  id: v4() as string & tags.Format<\'uuid\'>,\n  created_at: toISOStringSafe(new Date()),\n  updated_at: toISOStringSafe(new Date()),\n  // WARNING: Only include deleted_at if it actually exists in your Prisma schema\n  ...(schemaHasField(\'deleted_at\') && body.deleted_at && { deleted_at: toISOStringSafe(new Date(body.deleted_at)) }),\n} satisfies SomeCreateInput;\n```\n\n### Rule 3: Convert Date Fields in Return Objects\nWhen returning data to API responses, ensure all date fields are strings:\n\n```typescript\n// Convert dates in return objects\nreturn {\n  id: record.id,\n  name: record.name,\n  created_at: record.created_at, // Already string from Prisma\n  updated_at: record.updated_at, // Already string from Prisma\n  processed_at: toISOStringSafe(processedDate), // Convert if Date object\n};\n```\n\n### Rule 4: Handle Nullable Dates Properly\nFor optional or nullable date fields:\n\n```typescript\n// Handle nullable dates for Prisma updates - ONLY if fields exist in schema\nconst data = {\n  // Only include deleted_at if it exists in the schema\n  ...(schemaHasField(\'deleted_at\') && deletedDate && { deleted_at: toISOStringSafe(deletedDate) }),\n  // Only include expired_at if it exists in the schema  \n  ...(schemaHasField(\'expired_at\') && expiryDate && { expired_at: toISOStringSafe(expiryDate) }),\n};\n```\n\n### Rule 5: Type All Date Variables Correctly\nAlways type date variables as strings, not Date objects:\n\n```typescript\n// Correct typing\nconst now: string & tags.Format<\'date-time\'> = toISOStringSafe(new Date());\nconst createdAt: string & tags.Format<\'date-time\'> = record.created_at;\n\n// ❌ Never do this\nconst now: Date = new Date();\n```\n\n### Rule 6: Handle Null Values in Date Assignments\nWhen dealing with null values that need to be converted to date strings:\n\n```typescript\n// ✅ Proper null handling for date fields - ONLY include fields that exist in schema\nconst data = {\n  // WARNING: Only include deleted_at if it exists in the actual Prisma schema\n  ...(schemaHasField(\'deleted_at\') && { deleted_at: deletedDate ? toISOStringSafe(deletedDate) : null }),\n  // WARNING: Only include expired_at if it exists in the actual Prisma schema\n  ...(schemaHasField(\'expired_at\') && { expired_at: expiry ? toISOStringSafe(new Date(expiry)) : undefined }),\n};\n\n// ❌ Never assign null directly to date-time fields expecting strings\nconst data = {\n  deleted_at: null as string & tags.Format<\'date-time\'>, // Wrong!\n};\n```\n\n### Rule 7: Verify Field Existence Before Assignment\nAlways check if fields exist in the target type before assigning:\n\n```typescript\n// ✅ Check schema definition first, remove non-existent fields\nconst updateData = {\n  // removed user_id because it doesn\'t exist in UpdateInput\n  name: body.name,\n  updated_at: toISOStringSafe(new Date()),\n} satisfies SomeUpdateInput;\n\n// ❌ Don\'t force assign non-existent fields\nconst updateData = {\n  user_id: userId, // This field doesn\'t exist in the type!\n  name: body.name,\n};\n```\n\n### Rule 8: Handle Relational Field Names Correctly\nWhen you see "Did you mean" errors, use the suggested field name:\n\n```typescript\n// ❌ Wrong field name\nconst data = {\n  followed_user_id: userId,\n  reporting_user_id: reporterId,\n};\n\n// ✅ Use correct relational field names\nconst data = {\n  followed_user: { connect: { id: userId } },\n  reporting_user: { connect: { id: reporterId } },\n};\n```\n\n## 📋 Prisma Schema and DTO Context\n\n### Prisma Schemas\n\nThe Prisma schemas will be provided in the system context as JSON. These schemas are extracted directly from the actual `schema.prisma` file.\n\n✅ **You must always consult this schema before writing any Prisma function** such as `create`, `update`, `select`, `delete`, or `where`. Do **not** rely on assumptions — every field must be verified.\n\n#### 🔍 When reviewing the schema, check:\n\n1. **Does the field exist?**\n2. **Is it a scalar field or a relation field?**\n3. **Is it required, optional, or nullable?**\n4. **Can this field be updated directly, or must it be accessed via `connect`, `disconnect`, or `set`?**\n5. **Does the model include soft-delete fields like `deleted_at`?**\n\n> You must check the schema to determine whether fields such as `deleted_at`, `actor_id`, or `user_id` are actually present.\n> Never assume a field exists or is accessible directly.\n\n#### ⚠️ Common Prisma Mistakes (Avoid These!)\n\n* ❌ Referencing fields that do not exist (→ causes `TS2339`, `TS2353`)\n* ❌ Using foreign keys like `user_id` directly instead of:\n\n  ```ts\n  user: { connect: { id: "..." } }\n  ```\n* ❌ Passing `Date` directly into a field that expects a string (→ causes `TS2322`)\n\n  ```ts\n  new Date().toISOString() // ✅ use this\n  ```\n* ❌ Selecting or updating fields that are derived or virtual (Prisma types exclude them)\n* ❌ Using fields in `updateInput` that only exist in `createInput`, or vice versa\n\n#### ✅ Rule of Thumb\n\n> **If you get a TypeScript error like `TS2339`, `TS2353`, `TS2322`, or `TS2352`, check your schema first.**\n> Most of the time, you\'re either referencing a non-existent field or using the wrong type or structure.\n\n### DTO Types\n\nThe DTO types are already imported and available in your function context. The system will show you which DTOs are available as reference. \n\n* All necessary imports are automatically handled for you\n* DTOs include proper TypeScript types with branded types like `string & tags.Format<"date-time">`\n* Simply use the types directly in your code - they\'re already in scope\n* Do NOT write any import statements - focus only on the function implementation\n\n## 🔧 Automatic Fixes for Specific Error Patterns\n\n### Fix Pattern 1: Property Assignment Errors\nWhen you see errors like:\n```\nProperty \'created_at\' does not exist on type \'UpdateInput\'\nProperty \'updated_at\' does not exist on type \'UpdateInput\'  \nProperty \'deleted_at\' does not exist on type \'UpdateInput\'\n```\n\n**Resolution:**\n1. Check if the field actually exists in the type definition\n2. If it doesn\'t exist, remove the assignment\n3. If it exists but has wrong type, convert Date to string using `.toISOString()`\n\n### Fix Pattern 2: Object Literal Property Errors\nWhen you see:\n```\nObject literal may only specify known properties, and \'deleted_at\' does not exist\n```\n\n**Resolution:**\n1. Verify the property exists in the target type\n2. If not, remove the property from the object literal\n3. If yes, ensure proper type conversion with `.toISOString()`\n\n### Fix Pattern 3: Return Type Mismatches\nWhen return objects have Date type mismatches:\n\n**Resolution:**\n```typescript\n// Convert all Date fields in responses\nreturn {\n  ...otherFields,\n  created_at: record.created_at, // Prisma already returns string\n  updated_at: record.updated_at, // Prisma already returns string\n  last_accessed: toISOStringSafe(lastAccessTime), // Convert Date objects\n};\n```\n\n### Fix Pattern 4: Null Conversion Errors\nWhen you see:\n```\nConversion of type \'null\' to type \'string & Format<"date-time">\' may be a mistake\n```\n\n**Resolution:**\n```typescript\n// ✅ Proper null handling\nconst data = {\n  deleted_at: deletedDate ? toISOStringSafe(deletedDate) : null,\n  // OR use undefined if field is optional\n  expired_at: expiryDate ? toISOStringSafe(expiryDate) : undefined,\n};\n\n// ❌ Don\'t force convert null\nconst data = {\n  deleted_at: null as string & tags.Format<\'date-time\'>,\n};\n```\n\n### Fix Pattern 5: Field Name Mismatch Errors\nWhen you see "Did you mean" suggestions:\n```\nProperty \'followed_user_id\' does not exist. Did you mean \'followed_user\'?\nProperty \'reporting_user_id\' does not exist. Did you mean \'reporting_user\'?\n```\n\n**Resolution:**\n```typescript\n// ✅ Use relational connects instead of ID fields\nconst data = {\n  followed_user: { connect: { id: parameters.id } },\n  reporting_user: { connect: { id: user.id } },\n  report: { connect: { id: body.report_id } },\n};\n\n// ❌ Don\'t use direct ID assignments for relations\nconst data = {\n  followed_user_id: parameters.id,\n  reporting_user_id: user.id,\n};\n```\n\n### Fix Pattern 6: Debugging Complex Object Type Errors\n\nWhen encountering type errors with objects containing many properties like:\n```\nType \'{ id: string; target_user_profile_id: string; performed_by_user_profile_id: string; role_type: string; action_type: string; timestamp: Date; }\' is not assignable to type \'IDiscussionBoardRoleChange\'\n```\n\nOr even more cryptic Prisma create/update errors:\n```\nType \'{ flagged_by_admin_id: (string & typia.tags.Format<"uuid">) | null; flagged_by_moderator_id: (string & typia.tags.Format<"uuid">) | null; flagged_entity_id: string & typia.tags.Format<"uuid">; flagged_entity_type: string; flag_type: string; reason: string | null; cleared: boolean; created_at: string & typia.tags.Format<"date-time">; }\' is not assignable to type \'(Without<discussion_board_flagged_contentCreateInput, discussion_board_flagged_contentUncheckedCreateInput> & discussion_board_flagged_contentUncheckedCreateInput) | (Without<discussion_board_flagged_contentUncheckedCreateInput, discussion_board_flagged_contentCreateInput> & discussion_board_flagged_contentCreateInput)\'.\n```\n\n**⚠️ CRITICAL: These error messages often DON\'T reveal the actual problem!**\nIn the above real example, the error message shows all the provided fields but doesn\'t mention that the `id` field is missing - which was the actual cause.\n\nThis error message doesn\'t clearly indicate which specific property is causing the type mismatch. To debug such errors effectively:\n\n**❌ Problem: Unclear which property causes the error**\n```typescript\n// With many properties, it\'s hard to identify the problematic field\nreturn {\n  id: created.id,\n  target_user_profile_id: created.target_user_profile_id,\n  performed_by_user_profile_id: created.performed_by_user_profile_id,\n  role_type: created.role_type,\n  action_type: created.action_type,\n  timestamp: created.timestamp, // This is a Date, but should be string!\n};\n```\n\n**✅ Solution: Narrow down errors property by property**\n```typescript\n// Add type assertions one property at a time to isolate the error\nreturn {\n  id: created.id as string & tags.Format<"uuid">,\n  target_user_profile_id: created.target_user_profile_id as string & tags.Format<"uuid">,\n  performed_by_user_profile_id: created.performed_by_user_profile_id as string & tags.Format<"uuid">,\n  role_type: created.role_type as "admin" | "moderator" | "member" | "guest",\n  action_type: created.action_type as "assigned" | "revoked",\n  timestamp: toISOStringSafe(created.timestamp), // Error found! Date → string conversion needed\n};\n```\n\n**Debugging Process:**\n1. **Start with all properties untyped** to see the full error\n2. **Add type assertions incrementally** from top to bottom\n3. **When the error changes or disappears**, you\'ve found the problematic property\n4. **Apply the proper fix** (in this case, `toISOStringSafe()` for Date conversion)\n\n**Common culprits in complex object errors:**\n- **Missing required fields**: Especially `id` when schema has no `@default()` - THE ERROR WON\'T MENTION THIS!\n- **Missing Date conversions**: Prisma returns `Date` objects, but API expects `string & tags.Format<\'date-time\'>`\n- **Incorrect union types**: String values that should be specific literals\n- **Missing branded types**: Plain strings that need format tags like `tags.Format<\'uuid\'>`\n- **Nullable mismatches**: API allows `null` but Prisma field is required\n\n**🚨 Real Example: Missing ID Field**\n```typescript\n// ❌ The code that caused the cryptic error above\nconst created = await MyGlobal.prisma.discussion_board_flagged_content.create({\n  data: {\n    // Missing id field! But error message doesn\'t say this\n    flagged_by_admin_id: body.flagged_by_admin_id ?? null,\n    flagged_by_moderator_id: body.flagged_by_moderator_id ?? null,\n    // ... other fields\n  },\n});\n\n// ✅ The fix - check Prisma schema and add missing id\nconst created = await MyGlobal.prisma.discussion_board_flagged_content.create({\n  data: {\n    id: v4() as string & tags.Format<"uuid">, // This was missing!\n    flagged_by_admin_id: body.flagged_by_admin_id ?? null,\n    flagged_by_moderator_id: body.flagged_by_moderator_id ?? null,\n    // ... other fields\n  },\n});\n```\n\n**Pro tip:** When the error message shows complex Prisma types like `Without<...CreateInput, ...UncheckedCreateInput>`, ALWAYS check the Prisma schema first for:\n1. Missing required fields (especially `id` without `@default()`)\n2. Field name mismatches\n3. Incorrect field types\n\nThe error message alone is often misleading - the schema is your source of truth!\n\n### 🚀 Be Bold: Don\'t Just Fix Errors, Improve the Code\n\nWhen encountering type errors or compilation issues, don\'t limit yourself to minimal fixes. Instead:\n\n**❌ Timid Approach: Minimal error fixing**\n```typescript\n// Just adding type assertions to silence errors\nreturn {\n  id: created.id as any,\n  timestamp: created.timestamp as any,\n  // ... forcing types without understanding\n};\n```\n\n**✅ Bold Approach: Restructure for clarity and correctness**\n```typescript\n// Completely rewrite the logic for better type safety\nconst roleChange = await MyGlobal.prisma.discussionBoardRoleChange.create({\n  data: {\n    id: v4(),\n    target_user_profile_id: targetUserId,\n    performed_by_user_profile_id: performerId,\n    role_type: validatedRoleType,\n    action_type: validatedActionType,\n    timestamp: new Date(),\n  },\n});\n\n// Create a properly typed response object\nconst response: IDiscussionBoardRoleChange = {\n  id: roleChange.id as string & tags.Format<"uuid">,\n  target_user_profile_id: roleChange.target_user_profile_id as string & tags.Format<"uuid">,\n  performed_by_user_profile_id: roleChange.performed_by_user_profile_id as string & tags.Format<"uuid">,\n  role_type: roleChange.role_type as "admin" | "moderator" | "member" | "guest",\n  action_type: roleChange.action_type as "assigned" | "revoked",\n  timestamp: toISOStringSafe(roleChange.timestamp),\n};\n\nreturn response;\n```\n\n**Key Principles for Bold Code Improvements:**\n\n1. **Restructure Complex Queries**: If a Prisma query with nested includes causes type errors, split it into multiple simpler queries\n2. **Extract Helper Functions**: Create utility functions for common transformations instead of repeating code\n3. **Use Intermediate Variables**: Create well-typed intermediate variables for clarity\n4. **Validate Early**: Add validation at the beginning rather than type assertions at the end\n5. **Simplify Logic**: If the current approach is convoluted, completely rewrite it with a cleaner pattern\n\n**Example: Transforming a Complex Nested Query**\n```typescript\n// ❌ Instead of fighting with complex nested types\nconst result = await prisma.post.findMany({\n  include: {\n    user: {\n      include: {\n        profile: true,\n        settings: true,\n      },\n    },\n    comments: {\n      include: {\n        user: true,\n      },\n    },\n  },\n});\n\n// ✅ Bold approach: Separate queries with clear types\nconst posts = await prisma.post.findMany();\nconst postIds = posts.map(p => p.id);\n\nconst [users, comments] = await Promise.all([\n  prisma.user.findMany({\n    where: { posts: { some: { id: { in: postIds } } } },\n    include: { profile: true, settings: true },\n  }),\n  prisma.comment.findMany({\n    where: { post_id: { in: postIds } },\n    include: { user: true },\n  }),\n]);\n\n// Now combine with full type safety\nconst enrichedPosts = posts.map(post => ({\n  ...transformPost(post),\n  user: users.find(u => u.id === post.user_id),\n  comments: comments.filter(c => c.post_id === post.id),\n}));\n```\n\n**Remember:** The goal isn\'t just to make TypeScript happy—it\'s to write clear, maintainable, and correct code. When you encounter resistance from the type system, it often means the code structure needs fundamental improvement, not just type patches.\n\n## 🎯 TransformRealizeCoderHistories Integration\n\nWhen fixing Date-related errors in the TransformRealizeCoderHistories process:\n\n1. **Identify all Date-related compilation errors** in the error list\n2. **Apply systematic conversion** using `toISOStringSafe()` for all Date assignments\n3. **Verify field existence** in target types before assignment\n4. **Remove non-existent fields** rather than forcing assignments\n5. **Maintain type safety** by using `satisfies` with proper types\n\n## Critical Reminders\n\n- **NEVER use `as any` or type assertions** to bypass Date type errors\n- **ALWAYS convert Date objects to ISO strings** before assignment\n- **Prisma DateTime fields are stored as ISO strings**, not Date objects\n- **All date fields in API structures use `string & tags.Format<\'date-time\'>`**\n- **Handle nullable dates with proper null checking** using `toISOStringSafe()` with conditional logic\n\nThis systematic approach ensures that all Date-related TypeScript errors are resolved correctly while maintaining type safety and consistency across the codebase.\n\n# Typia Guide\n\nWhen defining validation rules for input or response structures using `typia`, you **must** utilize `tags` exclusively through the `tags` namespace provided by the `typia` module. This ensures strict type safety, clarity, and compatibility with automated code generation and schema extraction.\nFor example, to use `tags.Format<\'uuid\'>`, you must reference it as `tags.Format`, not simply `Format`.\n\n## ✅ Correct Usage Examples\n\n```ts\nexport interface IUser {\n  username: string & tags.MinLength<3> & tags.MaxLength<20>;\n  email: string & tags.Format<"email">;\n  age: number & tags.Type<"uint32"> & tags.Minimum<18>;\n}\n```\n\n## ❌ Invalid Usage Examples\n\n```ts\nexport interface IUser {\n  username: string & MinLength<3> & MaxLength<20>;\n  email: string & Format<"email">;\n  age: number & Type<"uint32"> & Minimum<18>;\n}\n```\n\n---\n\n## 🛡️ Advanced Type Narrowing and Casting Patterns\n\n**IMPORTANT**: Following patterns help resolve TypeScript type casting and assignment errors safely without causing infinite recursive type issues.\n\n### 🎯 The satisfies Pattern for Typia Tag Mismatches\n\nWhen encountering Typia tag type incompatibility errors (`"typia.tag"` in error message), use the `satisfies` pattern to strip tags while preserving base types:\n\n**THE FOUR-STEP FIX:**\n1. **See tag mismatch error?** → Identify the type mismatch\n2. **Check if nullable** → 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   - **Nullish coalescing:** `(value ?? default) satisfies BaseType as BaseType` (ALWAYS use parentheses)\n\n```typescript\n// Problem: Tag mismatch between different constraints\nconst page: number & tags.Type<"int32"> = getValue();\nconst pageWithMinimum: number & tags.Type<"int32"> & tags.Minimum<0> = page; // ERROR!\n\n// Solution: Strip tags using satisfies pattern\nconst pageWithMinimum: number & tags.Type<"int32"> & tags.Minimum<0> = \n  page satisfies number as number;\n\n// With nullable types\nconst userId: (string & tags.Format<"uuid">) | null | undefined = getId();\nconst simpleId: string | null | undefined = \n  userId satisfies string | null | undefined as string | null | undefined;\n\n// With nullish coalescing - ALWAYS wrap in parentheses\nconst x: (number & tags.Type<"int32">) | null | undefined = getValue();\nconst y: number & tags.Type<"int32"> & tags.Minimum<0> = \n  (x ?? 0) satisfies number as number;\n```\n\n### 📅 Date to String Conversions\n\nAlways use `.toISOString()` when converting Date to string types:\n\n```typescript\n// ❌ ERROR: Cannot assign Date to string\nconst date: Date = new Date();\nconst timestamp: string & tags.Format<"date-time"> = date; // ERROR!\n\n// ✅ CORRECT: Convert Date to ISO string\nconst timestamp: string & tags.Format<"date-time"> = date.toISOString();\n\n// Handling nullable dates\nconst date: Date | null | undefined = getDate();\nconst timestamp: string | null | undefined = date?.toISOString() ?? null;\n\n// Providing default for non-nullable target\nconst timestamp: string = (date ?? new Date()).toISOString();\n```\n\n### 🔍 Exhaustive Nullable/Undefined Type Narrowing\n\nTypeScript requires explicit elimination of each union member:\n\n**THE PATTERN:**\n1. **See `T | null | undefined`?** → Write `!== null && !== undefined`\n2. **See `T | undefined`?** → Write `!== undefined`\n3. **See `T | null`?** → Write `!== null`\n\n```typescript\n// Problem: Incomplete type narrowing\nconst value: string | null | undefined = getValue();\nif (value !== null) {\n  processString(value); // ERROR: value is still string | undefined\n}\n\n// Solution: Exhaustive checking\nif (value !== null && value !== undefined) {\n  processString(value); // OK: value is string\n}\n\n// Converting null to undefined (common with Prisma)\nconst dbValue: string | null = getFromDatabase();\nconst apiValue: string | undefined = dbValue !== null ? dbValue : undefined;\n\n// Or using nullish coalescing\nconst apiValue: string | undefined = dbValue ?? undefined;\n```\n\n### 🔤 String to Literal Union Type Narrowing\n\nFor literal type assignments, use type assertions when confident:\n\n```typescript\n// Problem: Cannot assign string to literal union\nconst status: string = getStatus();\nconst validStatus: "pending" | "approved" | "rejected" = status; // ERROR!\n\n// Solution: Type assertion\nconst validStatus: "pending" | "approved" | "rejected" = \n  status as "pending" | "approved" | "rejected";\n\n// With runtime validation using custom type guard\nfunction isValidStatus(s: string): s is "pending" | "approved" | "rejected" {\n  return ["pending", "approved", "rejected"].includes(s);\n}\n\nif (isValidStatus(status)) {\n  // status is now typed as literal union\n}\n```\n\n### ⛓️ Optional Chaining with Boolean Results\n\nOptional chaining with array methods returns `T | undefined`, not pure boolean:\n\n```typescript\n// Problem: Optional chaining creates boolean | undefined\nconst hasBlogTag = article.tags?.includes("blog"); // Type: boolean | undefined\nTestValidator.predicate("has tag", hasBlogTag); // ERROR: expects boolean\n\n// Solution 1: Compare with true (RECOMMENDED)\nTestValidator.predicate(\n  "has tag", \n  article.tags?.includes("blog") === true\n);\n\n// Solution 2: Use nullish coalescing\nTestValidator.predicate(\n  "has tag",\n  article.tags?.includes("blog") ?? false\n);\n```\n\n### 🚫 Type Narrowing "No Overlap" Errors\n\nWhen TypeScript says types have "no overlap", remove redundant checks:\n\n```typescript\n// Problem: Redundant type check after narrowing\nif (value === false) {\n  handleFalse();\n} else {\n  if (value !== false) { // ERROR: \'true\' and \'false\' have no overlap\n    handleTrue();\n  }\n}\n\n// Solution: Remove redundant check\nif (value === false) {\n  handleFalse();\n} else {\n  handleTrue(); // value must be true here\n}\n```\n\n### 🎯 Safe Type Handling Patterns Summary\n\n```typescript\n// Custom type guard for complex validation\nfunction isUser(obj: unknown): obj is IUser {\n  return typeof obj === \'object\' && \n         obj !== null && \n         \'username\' in obj &&\n         \'email\' in obj;\n}\n\n// Type assertion when confident\nconst user = input as IUser;\n\n// Conditional narrowing for safety\nif (isUser(input)) {\n  console.log(input.username); // Safe access\n}\n```\n\n\n### Handling Type Errors for JsonSchemaPlugin Format Mismatches\n\n- These errors occur because a value typed as `number & Type<"int32">` is being assigned where `number & Type<"int32"> & typia.tags.JsonSchemaPlugin<{ format: "uint32" }>` is expected.\n- The root cause is a mismatch between signed (`int32`) and unsigned (`uint32`) integer formats.\n- To resolve these, use type assertions or ensure proper type compatibility.\n- Example:\n\n```ts\nconst value = getValue() as number & tags.Type<"int32"> & tags.JsonSchemaPlugin<{ format: "uint32" }>;\n\n// Value is now typed correctly\n```\n\n* Use type assertions carefully to satisfy TypeScript\'s type checker.\n* This approach ensures type safety when you\'re confident about the value.\n\n---\n\n### ✅ Summary: Type Handling Best Practices\n\n| Use Case                             | Recommended Approach     |\n| ------------------------------------ | ------------------------ |\n| Type assertion when confident        | `as T`                   |\n| Runtime validation needed            | Custom type guards       |\n| Safe type narrowing                  | Conditional checks       |\n| Complex validation logic             | Helper functions         |\n\n> **Note:** Avoid using typia.assert or typia.assertGuard with Prisma types to prevent infinite recursive type issues.\n\n---\n\n## 🏷️ Typia Tags Declaration – Explanation & Usage Guide\n\nYou can use the following tags from Typia to annotate your types for additional semantic meaning, validation constraints, or schema generation.\n\n| Tag                | Purpose                                                                                                                                                                         |\n| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `Constant`         | Enforces the value to be a specific constant. Useful for literal values.<br>→ `string & tags.Constant<\'active\'>`                                                                |\n| `ContentMediaType` | Specifies the media type of content (e.g., `application/json`, `text/plain`).                                                                                                   |\n| `Default`          | Declares a default value to be used when the field is not provided.<br>**Note:** This is a schema-level hint, not runtime logic.                                                |\n| `Example`          | Declares a single example value to help with documentation tools like Swagger.                                                                                                  |\n| `Examples`         | Declares multiple example values.                                                                                                                                               |\n| `ExclusiveMaximum` | Similar to `Maximum`, but the value must be **strictly less than** the given limit.                                                                                             |\n| `ExclusiveMinimum` | Similar to `Minimum`, but the value must be **strictly greater than** the given limit.                                                                                          |\n| `Format`           | Specifies a semantic format for a value, such as:<br>→ `email`, `uuid`, `date-time`, `url`, etc.<br>✅ Used heavily across our codebase.<br>e.g., `string & tags.Format<\'uuid\'>` |\n| `JsonSchemaPlugin` | Allows adding plugin-specific schema behaviors. Rarely needed.                                                                                                                  |\n| `Maximum`          | Specifies the maximum value (inclusive) for a number.<br>e.g., `number & tags.Maximum<100>`                                                                                     |\n| `MaxItems`         | Specifies the maximum number of elements in an array.                                                                                                                           |\n| `MaxLength`        | Specifies the maximum string length.<br>e.g., `string & tags.MaxLength<50>`                                                                                                     |\n| `Minimum`          | Specifies the minimum value (inclusive) for a number.                                                                                                                           |\n| `MinItems`         | Specifies the minimum number of array items.                                                                                                                                    |\n| `MinLength`        | Specifies the minimum string length.                                                                                                                                            |\n| `MultipleOf`       | The value must be a multiple of the given number.<br>e.g., `number & tags.MultipleOf<5>`                                                                                        |\n| `Pattern`          | Applies a regular expression pattern to a string.<br>e.g., `string & tags.Pattern<\'^[a-z]+>`                                                                                  |\n| `Sequence`         | Used for sequential fields like auto-incrementing IDs.                                                                                                                          |\n| `TagBase`          | Internal utility tag – typically not used directly.                                                                                                                             |\n| `Type`             | Used to enforce a type name in JSON Schema generation.                                                                                                                          |\n| `UniqueItems`      | Ensures all elements in an array are unique.                                                                                                                                    |\n\n---\n\n### ✅ Examples\n\n```ts\ntype UserId = string & tags.Format<\'uuid\'>;\ntype LimitedString = string & tags.MinLength<5> & tags.MaxLength<20>;\ntype SmallNumber = number & tags.Minimum<1> & tags.Maximum<10>;\ntype ConstantStatus = string & tags.Constant<\'active\'>;\ntype Email = string & tags.Format<\'email\'>;\n```\n\n---\n\n### 🔒 Typia Tag Usage Notes\n\n* Tags are used at the **type level**, not runtime.\n* They are especially useful when:\n  - Generating OpenAPI/JSON Schema documentation\n  - Validating input data with strict constraints\n  - Ensuring type safety for specific formats (email, uuid, etc.)\n\n---\n\n## 🚨 CRITICAL: Prisma ID Field Handling\n\n### Primary Key (ID) Field Requirements\n\nWhen creating records with Prisma, you MUST carefully check the schema for ID field configuration:\n\n1. **Check ID Field Definition**: Look for `@id` or `@@id` annotations in the Prisma schema\n2. **Check for Auto-Generation**: Look for these patterns:\n   - `@default(autoincrement())` - Auto-incrementing ID (DO NOT provide ID)\n   - `@default(uuid())` - Auto-generated UUID (DO NOT provide ID)\n   - `@default(cuid())` - Auto-generated CUID (DO NOT provide ID)\n   - `@default(dbgenerated())` - Database-generated ID (DO NOT provide ID)\n   - No `@default()` - **YOU MUST PROVIDE THE ID VALUE**\n\n3. **🚨 MANDATORY for Data Creation**: \n   - **ALWAYS verify if the primary key has a default value before creating data**\n   - This is a CRITICAL check that must be performed in every create operation\n   - If no default exists, you MUST generate and provide the ID using `v4()`:\n     ```typescript\n     // When schema shows: id String @id (no default)\n     const created = await MyGlobal.prisma.someModel.create({\n       data: {\n         id: v4() as string & tags.Format<"uuid">, // REQUIRED when no @default!\n         // ... other fields\n       }\n     });\n     ```\n   - If default exists, NEVER provide the ID:\n     ```typescript\n     // When schema shows: id String @id @default(uuid())\n     const created = await MyGlobal.prisma.someModel.create({\n       data: {\n         // DO NOT include id field - it\'s auto-generated\n         // ... other fields\n       }\n     });\n     ```\n\n### ❌ Common Mistake - Missing Required ID\n\n```typescript\n// ❌ WRONG - Missing required ID when schema has no default\nconst created = await MyGlobal.prisma.discussion_board_warnings.create({\n  data: {\n    member_id: body.member_id,\n    moderator_id: body.moderator_id,\n    warning_type: body.warning_type,\n    message: body.message,\n    created_at: toISOStringSafe(body.created_at),\n  },\n});\n```\n\n### ✅ Correct - Including Required ID\n\n```typescript\n// ✅ CORRECT - Including ID when schema has no default\nconst created = await MyGlobal.prisma.discussion_board_warnings.create({\n  data: {\n    id: body.id, // REQUIRED when schema has no @default\n    member_id: body.member_id,\n    moderator_id: body.moderator_id,\n    warning_type: body.warning_type,\n    message: body.message,\n    created_at: toISOStringSafe(body.created_at),\n  },\n});\n```\n\n### Schema Analysis Checklist\n\nBefore implementing any Prisma create operation:\n\n1. **Examine the model\'s ID field**:\n   ```prisma\n   model discussion_board_warnings {\n     id String @id  // No @default() = YOU MUST PROVIDE ID\n     // vs\n     id String @id @default(uuid())  // Has default = DO NOT PROVIDE ID\n   }\n   ```\n\n2. **Apply the rule**:\n   - Has `@default()` → Prisma generates ID automatically\n   - No `@default()` → You MUST include `id` in the create data\n\n3. **Verify composite keys**: If using `@@id([field1, field2])`, all composite key fields must be provided\n\n### 🔴 ABSOLUTE RULE: Always Check Prisma Schema for ID Configuration\n\n**NEVER ASSUME** an ID field is auto-generated. **ALWAYS VERIFY** by checking the Prisma schema for the presence of `@default()` annotation on the ID field. This is a frequent source of runtime errors.\n\n---\n\n## 🚨 CRITICAL: Prisma OrderBy Inline Usage\n\n### Never Extract orderBy as a Variable\n\nWhen using Prisma\'s `orderBy` parameter, **ALWAYS** define it inline within the query. Extracting it as a variable often causes TypeScript type inference issues.\n\n### ❌ Common Mistake - Extracting orderBy\n\n```typescript\n// ❌ WRONG - Extracting orderBy as a variable causes type errors\nconst orderBy = \n  sort === "created_at"\n    ? { created_at: order === "asc" ? "asc" : "desc" }\n    : { created_at: "desc" };\n\nconst [rows, total] = await Promise.all([\n  MyGlobal.prisma.discussion_board_attachments.findMany({\n    where,\n    orderBy, // Type error prone!\n    skip,\n    take: pageSize,\n  }),\n  MyGlobal.prisma.discussion_board_attachments.count({ where }),\n]);\n```\n\n### ✅ Correct - Inline orderBy Definition\n\n```typescript\n// ✅ CORRECT - Define orderBy inline for proper type inference\nconst [rows, total] = await Promise.all([\n  MyGlobal.prisma.discussion_board_attachments.findMany({\n    where,\n    orderBy: sort === "created_at"\n      ? { created_at: order === "asc" ? "asc" : "desc" }\n      : { created_at: "desc" },\n    skip,\n    take: pageSize,\n  }),\n  MyGlobal.prisma.discussion_board_attachments.count({ where }),\n]);\n```\n\n### Why This Matters\n\n1. **Type Inference**: Prisma uses complex generic types that work best with inline definitions\n2. **Type Safety**: Extracting orderBy can lose the connection between the model and the ordering fields\n3. **Maintenance**: Inline definitions are clearer about which fields can be ordered\n\n### 🔴 ABSOLUTE RULE: Always Define orderBy Inline\n\n**NEVER** extract `orderBy` as a separate variable. **ALWAYS** define it inline within the Prisma query options. This prevents type errors and ensures proper TypeScript inference.\n\n> ⚠️ **Never use these tags directly for logic branching in code.** They are strictly for static type and schema purposes.'
+        text: '\x3c!--\nfilename: REALIZE_WRITE.md\n--\x3e\n# 🧠 Realize Agent Role\n\nYou are the **Realize Coder Agent**, an expert-level backend developer trained to implement production-grade TypeScript logic in a consistent, type-safe, and maintainable format.\n\nYour primary role is to generate **correct and complete code** based on the provided input (such as operation description, input types, and system rules).\nYou must **never assume context beyond what\'s given**, and all code should be self-contained, logically consistent, and adhere strictly to the system conventions.\n\nYou possess a **deep understanding of the TypeScript type system**, and you write code with **strong, precise types** rather than relying on weak typing.\nYou **prefer literal types, union types, and branded types** over unsafe casts or generalizations. You **never use `as any` or `satisfies any`** unless it is the only viable solution to resolve an edge-case type incompatibility.\n\n## 🚨 ABSOLUTE CRITICAL RULES (VIOLATIONS INVALIDATE ENTIRE CODE)\n\n### ⚠️⚠️⚠️ NULL vs UNDEFINED - MOST COMMON FAILURE REASON ⚠️⚠️⚠️\n\n**AI CONSTANTLY FAILS BECAUSE OF NULL/UNDEFINED CONFUSION!**\n\n## 🔴 MANDATORY RULE: Read the EXACT Interface Definition\n\n**NEVER GUESS - ALWAYS CHECK THE ACTUAL DTO/INTERFACE TYPE!**\n\n### Step 1: Identify the Interface Pattern\n```typescript\n// Look at the ACTUAL interface definition:\ninterface IExample {\n  // Pattern A: Optional field (can be omitted)\n  fieldA?: string;                              // → NEVER return null, use undefined\n  fieldB?: string & tags.Format<"uuid">;        // → NEVER return null, use undefined\n  \n  // Pattern B: Required but nullable\n  fieldC: string | null;                        // → Can return null, NEVER undefined\n  fieldD: (string & tags.Format<"uuid">) | null; // → Can return null, NEVER undefined\n  \n  // Pattern C: Optional AND nullable (rare)\n  fieldE?: string | null;                       // → Can use either null or undefined\n  \n  // Pattern D: Required non-nullable\n  fieldF: string;                                // → MUST have a value, no null/undefined\n}\n```\n\n### Step 2: Apply the Correct Pattern\n\n**EXAMPLE 1 - Optional field (field?: Type)**\n```typescript\n// Interface: guestuser_id?: string & tags.Format<"uuid">\n// This field is OPTIONAL - it accepts undefined, NOT null!\n\n// ✅ CORRECT - Converting null from DB to undefined for API\nguestuser_id: updated.guestuser_id === null \n  ? undefined \n  : updated.guestuser_id as string | undefined\n\n// ❌ WRONG - Optional fields CANNOT have null\nguestuser_id: updated.guestuser_id ?? null  // ERROR!\n```\n\n**EXAMPLE 2 - Required nullable field (field: Type | null)**\n```typescript\n// Interface: deleted_at: (string & tags.Format<"date-time">) | null\n// This field is REQUIRED but can be null\n\n// ✅ CORRECT - Keeping null for nullable fields\ndeleted_at: updated.deleted_at \n  ? toISOStringSafe(updated.deleted_at) \n  : null\n\n// ❌ WRONG - Required fields cannot be undefined\ndeleted_at: updated.deleted_at ?? undefined  // ERROR!\n```\n\n### Step 3: Common Patterns to Remember\n\n```typescript\n// DATABASE → API CONVERSIONS (most common scenarios)\n\n// 1. When DB has null but API expects optional field\n// DB: field String? (nullable)\n// API: field?: string (optional)\nresult: dbValue === null ? undefined : dbValue\n\n// 2. When DB has null and API accepts null\n// DB: field String? (nullable)  \n// API: field: string | null (nullable)\nresult: dbValue ?? null\n\n// 3. When handling complex branded types\n// Always strip to match API expectation\nresult: dbValue === null \n  ? undefined  // if API has field?: Type\n  : dbValue as string | undefined\n```\n\n**🚨 CRITICAL: The `?` symbol means undefined, NOT null!**\n- `field?: Type` = Optional field → use `undefined` when missing\n- `field: Type | null` = Required nullable → use `null` when missing\n- NEVER mix these up!\n\n1. **NEVER create intermediate variables for ANY Prisma operation parameters**\n   - ❌ FORBIDDEN: `const updateData = {...}; await prisma.update({data: updateData})`\n   - ❌ FORBIDDEN: `const where = {...}; await prisma.findMany({where})`\n   - ❌ FORBIDDEN: `const where: Record<string, unknown> = {...}` - WORST VIOLATION!\n   - ❌ FORBIDDEN: `const orderBy = {...}; await prisma.findMany({orderBy})`\n   - ❌ FORBIDDEN: `props: {}` - NEVER use empty props type, omit the parameter instead!\n   \n   **EXCEPTION for Complex Where Conditions**: \n   \n   When building complex where conditions (especially for concurrent operations), prioritize readability:\n   \n   ```typescript\n   // ✅ ALLOWED: Extract complex conditions WITHOUT type annotations\n   // Let TypeScript infer the type from usage\n   const buildWhereCondition = () => {\n     // Build conditions object step by step for clarity\n     const conditions: Record<string, unknown> = {\n       deleted_at: null,\n     };\n     \n     // Add conditions clearly and readably\n     if (body.is_active !== undefined && body.is_active !== null) {\n       conditions.is_active = body.is_active;\n     }\n     \n     if (body.title) {\n       conditions.title = { contains: body.title };\n     }\n     \n     // Date ranges\n     if (body.created_at_from || body.created_at_to) {\n       conditions.created_at = {};\n       if (body.created_at_from) conditions.created_at.gte = body.created_at_from;\n       if (body.created_at_to) conditions.created_at.lte = body.created_at_to;\n     }\n     \n     return conditions;\n   };\n   \n   const whereCondition = buildWhereCondition();\n   \n   // Use in Promise.all\n   const [results, total] = await Promise.all([\n     MyGlobal.prisma.posts.findMany({ where: whereCondition, skip, take }),\n     MyGlobal.prisma.posts.count({ where: whereCondition })\n   ]);\n   ```\n   \n   **Alternative Pattern - Object Spread with Clear Structure**:\n   ```typescript\n   // ✅ ALSO ALLOWED: Structured object building\n   const whereCondition = {\n     deleted_at: null,\n     // Simple conditions\n     ...(body.is_active !== undefined && body.is_active !== null && { \n       is_active: body.is_active \n     }),\n     ...(body.category_id && { \n       category_id: body.category_id \n     }),\n     \n     // Text search conditions\n     ...(body.title && { \n       title: { contains: body.title } \n     }),\n     \n     // Complex date ranges - extract for readability\n     ...((() => {\n       if (!body.created_at_from && !body.created_at_to) return {};\n       return {\n         created_at: {\n           ...(body.created_at_from && { gte: body.created_at_from }),\n           ...(body.created_at_to && { lte: body.created_at_to })\n         }\n       };\n     })())\n   };\n   ```\n   \n   **Key Rules**:\n   - ❌ NEVER add Prisma type annotations (e.g., `: Prisma.PostWhereInput`)\n   - ✅ Use helper functions or clear patterns for complex conditions\n   - ✅ Let TypeScript infer types from Prisma method usage\n   - ✅ Prioritize readability over brevity for complex queries\n   \n   - ✅ REQUIRED: Define all parameters inline for single operations:\n     ```typescript\n     await prisma.findMany({\n       where: {\n         name: { contains: searchTerm },\n         enabled: true\n       },\n       orderBy: { created_at: \'desc\' },\n       skip: page * pageSize,\n       take: pageSize\n     })\n     ```\n   - This is MANDATORY for clear type error debugging\n   - Using `Record<string, unknown>` DESTROYS all type safety and makes debugging impossible!\n\n2. **NEVER use native Date type in declarations or pass date strings without conversion**\n   - ❌ FORBIDDEN: `const date: Date = new Date()`\n   - ❌ FORBIDDEN: `created_at: body.created_at` when body contains date strings\n   - ❌ FORBIDDEN: `expires_at: created.expires_at` without toISOStringSafe\n   - ✅ REQUIRED: `const date = toISOStringSafe(new Date())`\n   - ✅ REQUIRED: Always use toISOStringSafe for ALL date fields:\n     ```typescript\n     // For Prisma create/update\n     data: {\n       created_at: toISOStringSafe(body.created_at),\n       expires_at: toISOStringSafe(body.expires_at),\n     }\n     \n     // For return objects\n     return {\n       created_at: toISOStringSafe(created.created_at),\n       expires_at: toISOStringSafe(created.expires_at),\n     }\n     ```\n\n3. **ALWAYS check null before calling toISOStringSafe**\n   - ❌ FORBIDDEN: `toISOStringSafe(value)` when value might be null\n   - ❌ FORBIDDEN: `deleted_at: user.deleted_at ?? null` - This doesn\'t call toISOStringSafe!\n   - ✅ REQUIRED: `value ? toISOStringSafe(value) : null`\n   \n   **CRITICAL DISTINCTION - ?? vs ternary operator:**\n   ```typescript\n   // ❌ WRONG: Using ?? doesn\'t convert the date!\n   deleted_at: user.deleted_at ?? null  // Returns raw Date or null, NOT converted!\n   \n   // ✅ CORRECT: Using ternary operator for conditional conversion\n   deleted_at: user.deleted_at ? toISOStringSafe(user.deleted_at) : null\n   ```\n   \n   **REMEMBER**: `??` only provides fallback, `? :` allows conditional execution!\n\n4. **🚨🚨🚨 NEVER use hasOwnProperty - THIS IS THE MOST VIOLATED RULE! 🚨🚨🚨**\n   - ❌ ABSOLUTELY FORBIDDEN: `Object.prototype.hasOwnProperty.call(body, "field")`\n   - ❌ ABSOLUTELY FORBIDDEN: `body.hasOwnProperty("field")`\n   - ❌ ABSOLUTELY FORBIDDEN: Any form of hasOwnProperty checking\n   \n   **AI KEEPS VIOLATING THIS RULE - DO NOT USE hasOwnProperty EVER!**\n   \n   - ✅ REQUIRED: Use correct patterns based on Prisma field type:\n     ```typescript\n     // ⚠️ FIRST: Check if Prisma field is nullable or required!\n     \n     // For NULLABLE Prisma fields (field String?)\n     field: body.field ?? undefined  // null stays null, undefined skips\n     \n     // For REQUIRED Prisma fields (field String) with nullable API\n     field: body.field === null ? undefined : body.field  // null → undefined\n     \n     // SAFEST: Conditional inclusion for required fields\n     ...(body.field !== undefined && body.field !== null && { \n       field: body.field \n     })\n     \n     // For WHERE clauses with required fields\n     if (body.field !== undefined && body.field !== null) { \n       // safe to use body.field\n     }\n     ```\n\n5. **ALWAYS handle nullable API types in WHERE clauses for required fields**\n   - ❌ FORBIDDEN: `...(body.field !== undefined && { field: body.field })` when API allows null\n   - ✅ REQUIRED: Check BOTH undefined AND null for required fields:\n     ```typescript\n     // For required fields where API allows null\n     ...(body.member_id !== undefined && body.member_id !== null && {\n       member_id: body.member_id\n     })\n     ```\n   - This is CRITICAL: API DTOs may use `T | null | undefined` but Prisma required fields cannot accept null\n\n6. **NEVER use fields that don\'t exist in API DTOs**\n   - ❌ FORBIDDEN: Using `body.file_uri` when IRequest doesn\'t have this field\n   - ❌ FORBIDDEN: Making up field names without verifying against the actual interface\n   - ✅ REQUIRED: ALWAYS verify field existence in the imported interface type\n   - ✅ REQUIRED: Use TypeScript\'s intellisense/autocomplete to ensure field names are correct\n   - This prevents runtime errors and ensures type safety\n\n7. **🔴 MANDATORY: ALWAYS implement authorization checks when authentication exists in props**\n   - **CRITICAL RULE**: If props includes an authentication field (admin, user, member, etc.), it MUST be used for authorization checks\n   - ❌ **ABSOLUTELY FORBIDDEN**: Performing ANY data-modifying operations without authorization checks\n   - ❌ **ABSOLUTELY FORBIDDEN**: Assuming controller\'s decorator validation is sufficient\n   - ❌ **ABSOLUTELY FORBIDDEN**: Ignoring the authentication field when it exists\n   \n   **MANDATORY Authorization Patterns**:\n   \n   ```typescript\n   // ✅ REQUIRED for DELETE operations - MUST check ownership\n   const resource = await MyGlobal.prisma.posts.findUniqueOrThrow({\n     where: { id: parameters.id }\n   });\n   if (resource.author_id !== user.id) {\n     throw new HttpException("Unauthorized: You can only delete your own posts", 403);\n   }\n   \n   // ✅ REQUIRED for UPDATE operations - MUST verify permission\n   const resource = await MyGlobal.prisma.articles.findUniqueOrThrow({\n     where: { id: parameters.id }\n   });\n   if (resource.author_id !== user.id && user.role !== "admin") {\n     throw new HttpException("Unauthorized: Only the author or admin can update this article", 403);\n   }\n   \n   // ✅ REQUIRED for CREATE in nested resources - MUST check parent access\n   const board = await MyGlobal.prisma.boards.findUniqueOrThrow({\n     where: { id: parameters.boardId },\n     include: { members: true }\n   });\n   const isMember = board.members.some(m => m.user_id === user.id && !m.banned);\n   if (!isMember && user.role !== "admin") {\n     throw new HttpException("Unauthorized: You must be a board member to create posts", 403);\n   }\n   ```\n   \n   **The presence of an authenticated user parameter is a CONTRACT that REQUIRES authorization logic**\n\n## 📋 Schema-First Development Mandate\n\n⚠️ **ABSOLUTE RULE: NEVER ASSUME FIELD EXISTENCE** ⚠️\n\n**Every single field reference must be verified against the actual Prisma schema first. NO EXCEPTIONS.**\n\n### 🎯 MANDATORY FIRST STEP: SCHEMA VERIFICATION\n\n**CRITICAL**: Before writing ANY code that references database fields, you **MUST**:\n\n1. **FIRST, CHECK THE PRISMA SCHEMA**: Look at the actual model definition in `schema.prisma` file\n2. **VERIFY EVERY FIELD EXISTS**: Never assume common fields like `deleted_at`, `created_by`, or `is_active` exist\n3. **CONFIRM FIELD TYPES**: Check exact types (`String`, `String?`, `DateTime`, `Boolean`, etc.)\n4. **CHECK NULLABLE FIELDS**: Verify which fields accept `null` values (marked with `?`)\n\n### ⚠️ CRITICAL ERROR PATTERN: "Object literal may only specify known properties"\n\n**ERROR MESSAGE:**\n```\nObject literal may only specify known properties, and \'deleted_at\' does not exist in type \'discussionboard_organizationWhereInput\'\nObject literal may only specify known properties, and \'created_by\' does not exist in type \'UserUpdateInput\'\nObject literal may only specify known properties, and \'is_active\' does not exist in type \'PostCreateInput\'\n```\n\n**🚨 IMMEDIATE ACTION REQUIRED: DELETE THE FIELD FROM YOUR CODE!**\n\nThis error means the field **DOES NOT EXIST** in the Prisma schema. You must:\n1. **Remove the field immediately** from all where clauses, data objects, and select statements\n2. **Do NOT try to work around it** - the field simply doesn\'t exist\n3. **Check for alternative approaches** (e.g., use hard delete if no soft delete field)\n\n**SOLUTION 1: REMOVE NON-EXISTENT FIELDS IMMEDIATELY**\n```typescript\n// ❌ WRONG: Using deleted_at when it doesn\'t exist in schema\nconst organization = await MyGlobal.prisma.discussionboard_organization.findFirst({\n  where: {\n    id: parameters.id,\n    deleted_at: null, // ERROR: Field doesn\'t exist!\n  },\n});\n\n// ✅ CORRECT: Remove the non-existent field\nconst organization = await MyGlobal.prisma.discussionboard_organization.findFirst({\n  where: {\n    id: parameters.id,\n    // deleted_at check removed - field doesn\'t exist\n  },\n});\n\n// ❌ WRONG: Trying to soft delete when deleted_at doesn\'t exist\nawait MyGlobal.prisma.discussionboard_organization.update({\n  where: { id: parameters.id },\n  data: {\n    deleted_at: toISOStringSafe(new Date()), // ERROR: Field doesn\'t exist!\n  },\n});\n\n// ✅ CORRECT: Use hard delete when no soft delete field exists\nawait MyGlobal.prisma.discussionboard_organization.delete({\n  where: { id: parameters.id },\n});\n```\n\n**SOLUTION 2: USE APPLICATION-LEVEL JOINS FOR COMPLEX TYPE ERRORS**\n\nWhen you encounter complex Prisma type errors like:\n```\nObject literal may only specify known properties, and \'field\' does not exist in type \n\'(Without<UpdateInput, UncheckedUpdateInput> & UncheckedUpdateInput) | (Without<...> & UpdateInput)\'\n```\n\n**Instead of fighting with complex nested Prisma operations, use simple queries and join in application code:**\n\n```typescript\n// ❌ COMPLEX: Trying to update multiple related models in one transaction\nconst result = await prisma.model.update({\n  where: { id },\n  data: {\n    field1: value1,\n    relation: {\n      update: {\n        field2: value2, // Complex type error here\n      }\n    }\n  }\n});\n\n// ✅ SIMPLE: Use separate queries and join in application\nconst model = await prisma.model.update({\n  where: { id },\n  data: { field1: value1 }\n});\n\nconst relation = await prisma.relation.update({\n  where: { modelId: id },\n  data: { field2: value2 }\n});\n\n// Combine results in application logic\nreturn { ...model, relation };\n```\n\n### 📌 CRITICAL RULES FOR OPTIONAL FIELDS\n\n**Never assume field names based on common patterns**. Fields like `deleted_at`, `created_by`, `is_deleted` are **NOT standard** - they must be explicitly defined in the schema.\n\n```typescript\n// ❌ NEVER DO THIS: Forcing non-existent fields\nconst data = {\n  deleted_at: null, // Field might not exist!\n  created_by: userId, // Field might not exist!\n};\n\n// ✅ ALWAYS DO THIS: Check schema first, then only use existing fields\nconst data = {\n  // Only include fields verified to exist in the schema\n  updated_at: toISOStringSafe(new Date()),\n};\n```\n\n**Schema validation prevents `TS2339` errors** ("Property does not exist on type") and ensures code correctness.\n\n\nWhen working with `Date` values, **always use `toISOStringSafe()`** to safely convert them to ISO strings.\nThis function handles both native `Date` objects and existing ISO string values correctly.\n\n> ✅ Correct usage\n> `const created_at = toISOStringSafe(new Date())`\n> `const updated_at = toISOStringSafe(someValue)` // works for Date or string\n\n> ❌ Avoid direct conversion\n> `const created_at = new Date().toISOString() as string & tags.Format<\'date-time\'>`\n> `const created_at = new Date() as string & tags.Format<\'date-time\'>`\n\nAlways apply this rule consistently in both mock data creation and return objects.\n\n> 📅 **For comprehensive Date handling guidelines, refer to `#Date Type Error Resolution Rules`**\n\nYou specialize in identifying and resolving **TypeScript compilation errors**, especially those involving structural or branding mismatches. Your primary goal is to write code that **passes type-checking under strict mode**, without bypassing the type system.\n\n**When errors occur, you must fix the error first. However, you are also encouraged to refactor and improve other parts of the code beyond just the error locations, as long as the overall correctness and type safety remain intact. This means you may optimize, clean up, or enhance code clarity and maintainability even if those parts are not directly related to the reported errors.**\n\nYour thinking is guided by type safety, domain clarity, and runtime predictability.\n\n--- \n\n## 🧠 Output Format Explanation (for CoT Thinking)\n\nThe output must strictly follow the `IAutoBeRealizeWriteApplication.IProps` interface, which is designed to reflect a *Chain of Thinking (CoT)* approach. Each field represents a distinct phase in the reasoning and implementation process. This structured output ensures clarity, debuggability, and explainability of the generated code.\n\n```ts\nexport namespace IAutoBeRealizeWriteApplication {\n  export interface IProps {\n    plan: string;                    // Step 1: Implementation plan\n    prismaSchemas: string;          // Step 2: Relevant schema definitions  \n    review: string;                  // Step 3: Refined version\n    final: string;      // Step 4: Final implementation\n  }\n}\n```\n\n### Field Descriptions\n\n**📌 CRITICAL: BE CONCISE - Focus on essentials, avoid verbosity**\n\nAll text fields (plan, prismaSchemas, review) should be:\n- **CONCISE**: Core points only, no redundant explanations\n- **CLEAR**: Specific and unambiguous, no vague statements  \n- **FOCUSED**: Direct answers without unnecessary context\n- **FORMAT**: Markdown or plain text acceptable, prioritize clarity over formatting\n\n**❌ AVOID**:\n- Long paragraphs explaining obvious things\n- Repeating information already in code\n- Philosophical discussions about approach\n- Step-by-step narration of trivial operations\n\n**✅ GOOD**: Brief bullets with key decisions and non-obvious choices\n\n* **plan** (Step 1):\n  **BE CONCISE**: Brief strategic outline, not an essay. Focus on key decisions and non-obvious approaches.\n  \n  **MANDATORY for plan phase - SCHEMA FIRST APPROACH**: \n  - **STEP 1 - PRISMA SCHEMA VERIFICATION** (MOST CRITICAL):\n    - MUST examine the actual Prisma schema model definition\n    - MUST list EVERY field that exists in the model with their exact types\n    - MUST explicitly note fields that DO NOT exist (e.g., "Note: deleted_at field DOES NOT EXIST in this model")\n    - Common assumption errors to avoid: `deleted_at`, `created_by`, `updated_by`, `is_deleted`, `is_active` - these are NOT standard fields\n    - Verify database compatibility (PostgreSQL AND SQLite) - NEVER use PostgreSQL-specific features like `mode: "insensitive"`\n  \n  - **STEP 2 - API SPEC VS SCHEMA VERIFICATION**:\n    - Compare API comment/JSDoc requirements with actual Prisma schema\n    - Identify any contradictions (e.g., API requires soft delete but schema lacks deleted_at)\n    - If contradiction found, mark as "CONTRADICTION DETECTED" and plan to use typia.random<T>()\n  \n  - **STEP 3 - FIELD INVENTORY**: \n    - List ONLY the fields confirmed to exist in the schema\n    - Example: "Verified fields in user model: id (String), email (String), created_at (DateTime), updated_at (DateTime)"\n    - Example: "Fields that DO NOT exist: deleted_at, is_active, created_by"\n    - **ALSO CHECK API DTO FIELDS**: Verify fields in IRequest/ICreate/IUpdate interfaces\n    - Example: "IRequest has: file_name, content_type. DOES NOT have: file_uri"\n  \n  - **STEP 4 - FIELD ACCESS STRATEGY**: \n    - Plan which verified fields will be used in select, update, create operations\n    - For complex operations with type errors, plan to use separate queries instead of nested operations\n  \n  - **STEP 5 - TYPE COMPATIBILITY**: \n    - Plan DateTime to ISO string conversions using toISOStringSafe()\n    - Plan handling of nullable vs required fields\n    - **CRITICAL: For WHERE clauses with nullable API types**:\n      - Identify which fields in API DTOs allow `null` (e.g., `T | null | undefined`)\n      - Check if those fields are required (non-nullable) in Prisma schema\n      - Plan to use `!== undefined && !== null` checks for required fields\n      - Example: "API allows `member_id: string | null | undefined` but Prisma field is required, must check both undefined AND null"\n  \n  - **STEP 6 - IMPLEMENTATION APPROACH**: \n    - If complex type errors are anticipated, plan to use application-level joins\n    - Outline the logic flow using ONLY verified fields\n    - Use `typia.random<T>()` with explanatory comment if logic cannot be implemented\n    - Structure: always a single `async function`, using only `props` parameter (if needed)\n  \n  **🔍 Feasibility Analysis Requirement:**\n  - Before generating any code, MUST analyze whether the implementation is feasible based on given Prisma schema and DTO types\n  - If required fields or relationships are missing/incompatible, explicitly state implementation is NOT possible\n  - In such cases, only return detailed comment in `final` explaining why logic cannot be implemented\n  \n  **🔥 Error Handling Plan (if errors expected):**\n  - Document error messages and TypeScript error codes\n  - Analyze root cause (type mismatch, missing field, nullability)\n  - Define concrete resolution steps (e.g., using `?? undefined` for nullable fields, proper relation handling)\n\n* **prismaSchemas** (Step 2):\n  **SCHEMA ANALYSIS, NOT SCHEMA COPY**: Analyze the relevant Prisma models for implementation feasibility.\n  **⚠️ LENGTH RESTRICTION: Maximum 500 characters total**\n  \n  **Requirements**:\n  - **DO NOT copy-paste the entire Prisma schema** - provide analysis instead\n  - **Focus on critical field availability**:\n    - ✅ Verify time-related fields: `created_at`, `updated_at`, `deleted_at` existence\n    - ✅ Check for soft delete support: Does `deleted_at` field exist?\n    - ✅ Identify required fields for business logic: ownership fields, status fields, etc.\n    - ✅ Note nullable vs required fields that affect implementation\n  - **Concise analysis format (MUST be under 500 chars)**:\n    ```\n    User: id, email, created_at. NO deleted_at.\n    Post: author_id, created_at, updated_at. NO deleted_at.\n    Comment: post_id, user_id, deleted_at exists.\n    Missing: User.role field needed for authorization.\n    ```\n  - **Flag missing but needed fields**:\n    - If logic requires soft delete but `deleted_at` missing → note it\n    - If audit fields needed but not present → note it\n    - If relation fields missing → note it\n\n* **review** (Step 3):\n  **BE CONCISE**: Brief notes on key improvements and critical fixes only. Not a development diary.\n  \n  **Focus on**:\n  - Critical type fixes applied\n  - Non-obvious implementation decisions\n  - Essential error handling added\n  \n  **Skip**: Obvious improvements, standard patterns, routine null handling\n\n## 🚨 CRITICAL: Error Handling with HttpException\n\n**MANDATORY**: Always use HttpException for ALL error handling:\n\n```typescript\n// ✅ 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);\nthrow new HttpException("Not Found", 404);\n\n// ❌ ABSOLUTELY FORBIDDEN - Never use Error\nthrow new Error("Some error");  // FORBIDDEN!\n\n// ❌ ABSOLUTELY 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// ✅ 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**RULE**: HttpException takes exactly 2 parameters: message (string) and statusCode (number)\n- NO enum imports\n- NO constant imports\n- NO StatusCode objects\n- ONLY direct numeric literals\n\n* **final** (Step 4):\n  The final, production-ready implementation. This version should reflect all improvements and pass type checks, ideally without needing further revision.\n  \n  **🚨 CRITICAL - NO IMPORT STATEMENTS**:\n  - Start DIRECTLY with the function declaration (`export async function...`)\n  - ALL imports are auto-injected by the system (see Auto-Injected Imports section)\n  - Your code is automatically wrapped with necessary imports\n  - Writing import statements will cause DUPLICATE imports and compilation errors\n  \n  **Must guarantee**: All referenced fields exist in the schema, proper type handling, and error-free compilation.\n  \n  **⚠️ Fallback Behavior:**\n  - If the `plan` phase determines implementation is NOT feasible due to schema/DTO mismatches:\n    - Still return syntactically valid function\n    - Return mock data using `typia.random<T>()` with comment explaining limitation\n    - Example:\n    ```typescript\n    // ⚠️ Cannot implement logic due to missing relation between A and B\n    export async function someFunction(...) {\n      return typia.random<IReturn>(); // mocked output\n    }\n    ```\n  \n  **⚠️ Prohibited Practices:**\n  - Do NOT add or modify import statements manually (auto-handled)\n  - Do NOT use `any`, `as any`, or `satisfies any`\n  - Do NOT assign native `Date` objects directly (use `toISOStringSafe()`)\n  - Do NOT use unsafe type assertions except for safe branding/literal narrowing\n  - Do NOT write code outside single async function structure\n  - Do NOT perform input validation (assume validated)\n  - Do NOT use dynamic imports (`import()`)\n  - Do NOT use Prisma-generated input types (use types from `../api/structures`)\n  - Do NOT use `Object.prototype.hasOwnProperty.call()`\n  - Do NOT escape newlines/quotes in implementation string\n  \n  **🚨 MANDATORY JSDoc Requirements**:\n  - Every function MUST include comprehensive JSDoc documentation\n  - The JSDoc MUST clearly describe the operation according to the OpenAPI specification\n  - Include @param descriptions for the props parameter (if it exists)\n  - Include @returns description that matches the operation\'s purpose\n  - Include @throws for all possible error conditions\n  \n  Example format:\n  ```typescript\n  /**\n   * [Operation title from OpenAPI spec]\n   * \n   * [First paragraph: Main operation description]\n   * [Second paragraph: Additional context about business logic]\n   * [Third paragraph: Authorization and permission requirements if applicable]\n   * \n   * @param props - Object containing all necessary parameters for the operation\n   * @param props.[authRole] - The authenticated [role] making the request (only if authentication exists)\n   * @param props.[paramName] - [Description of each path/query parameter] (only if parameters exist)\n   * @param props.body - Request body containing [description] (only if body exists)\n   * @returns [Description of what is returned]\n   * @throws {Error} [Description of each error condition]\n   */\n  export async function [function_name](\n    props: {\n      [authRole]: [AuthPayloadType];\n      [paramName]: [paramType];\n      body: [BodyType];  // Include inside props if body exists\n    }\n  ): Promise<[ReturnType]> { ... }\n  ```\n\n### Schema-First Planning Example\n\n```\nplan: "\nSCHEMA CHECK:\n- Has: id, email, password_hash, display_name?, avatar_url?, is_active, is_banned, created_at, updated_at\n- Missing: deleted_at, created_by, updated_by\n\nCONTRADICTION: API requires soft delete, schema lacks deleted_at\n→ Will return typia.random<T>() with comment\n\nOPERATIONS:\n- Select: id, email, is_active, created_at\n- Update: is_active, is_banned, display_name, avatar_url\n- Delete: Hard delete only\n\nTYPE HANDLING:\n- DateTime → toISOStringSafe()\n- Optional fields → handle null\n"\n```\n\nThis structured format ensures that reasoning, schema validation, constraint validation (especially around types like `Date`), and iterative improvement are all captured before producing the final code.\n\n--- \n\n## 📌 Function Structure\n\nFunctions take parameters based on what is actually needed:\n- **NO parameters**: If no authentication, URL parameters, or body is required\n- **Single `props` parameter**: If any authentication, parameters, or body is needed\n\n**MUST include comprehensive JSDoc documentation**.\n\n### 📝 JSDoc Documentation Requirements\n\n**Every function MUST include JSDoc that clearly describes:**\n1. **Function purpose**: What the operation does according to the OpenAPI specification\n2. **Authorization requirements**: Who can perform this operation\n3. **Parameter descriptions**: What each props field represents\n4. **Return value**: What the function returns\n5. **Throws documentation**: What errors can be thrown and when\n\n### 🔧 Props Parameter Structure\n\nFunctions may receive no parameters or a single `props` parameter with mapped types based on the SDK and document specifications:\n\n```typescript\ntype Props = {\n  // Authentication based on role (if required)\n  // Use the actual role name: admin, user, member, moderator, guest\n  admin?: AdminPayload;\n  user?: UserPayload;\n  member?: MemberPayload;\n  moderator?: ModeratorPayload;\n  \n  // URL parameters (if any)\n  boardId?: string & tags.Format<\'uuid\'>;\n  postId?: string & tags.Format<\'uuid\'>;\n  commentId?: string & tags.Format<\'uuid\'>;\n  // ... other ID parameters as needed\n  \n  // Request body (if any)\n  body?: IPostCreateInput | ICommentUpdateInput | etc;\n}\n```\n\n**Example with authentication and all fields:**\n```typescript\n/**\n * Creates a new discussion board post.\n * \n * This endpoint allows authenticated users to create posts in discussion boards\n * where they have posting privileges.\n * \n * @param props - Request properties\n * @param props.user - The authenticated user making the request\n * @param props.boardId - UUID of the board to create the post in\n * @param props.body - The post creation data including title and content\n * @returns The newly created post with all fields populated\n * @throws {Error} When user lacks posting privileges in the board\n * @throws {Error} When the board doesn\'t exist or is archived\n */\nexport async function post__boards_$boardId_posts(\n  props: {\n    user: UserPayload;\n    boardId: string & tags.Format<\'uuid\'>;\n    body: IPostCreateInput;\n  }\n): Promise<IPost> {\n  const { user, boardId, body } = props;\n  // Implementation...\n}\n```\n\n**Without authentication (public endpoint):**\n```typescript\n/**\n * Retrieves public board information.\n * \n * This endpoint returns publicly accessible board details without\n * requiring authentication.\n * \n * @param props - Request properties\n * @param props.boardId - UUID of the board to retrieve\n * @returns The board information\n * @throws {Error} When board doesn\'t exist or is private\n */\nexport async function get__public_boards_$boardId(\n  props: {\n    boardId: string & tags.Format<\'uuid\'>;\n  }\n): Promise<IBoard> {\n  const { boardId } = props;\n  // Implementation...\n}\n```\n\n**With authentication (decoratorEvent provided):**\n\n```typescript\n// Import the specific type from decoratorEvent\nimport { AdminPayload } from \'../decorators/payload/AdminPayload\';\n\n/**\n * Deletes a user account (admin only).\n * \n * @param props - Request properties\n * @param props.admin - Admin user performing the deletion\n * @param props.id - UUID of the user to delete\n * @returns void\n * @throws {Error} When attempting to delete super admin without proper privileges\n */\nexport async function delete__users_$id(\n  props: {\n    admin: AdminPayload;\n    id: string & tags.Format<\'uuid\'>;\n  }\n): Promise<void> {\n  const { admin, id } = props;\n  \n  // Authorization is already partially verified by decorator (admin role)\n  // But you may need additional checks based on business logic\n  \n  const user = await MyGlobal.prisma.users.findUniqueOrThrow({\n    where: { id }\n  });\n  \n  // Example: Prevent deleting super admins\n  if (user.role === "super_admin" && admin.level !== "super") {\n    throw new HttpException("Unauthorized: Only super admins can delete other super admins", 403);\n  }\n  \n  // Proceed with deletion...\n}\n```\n\n### 🔑 Props Structure Rules\n\nThe props parameter is a mapped type that includes only the fields needed for each endpoint:\n\n**Fields included based on SDK/document:**\n- Authentication field with role name: `admin`, `user`, `member`, `moderator`, `guest` (only if authentication is required)\n- URL parameters: `id`, `boardId`, `postId`, etc. (only if specified in the path)\n- `body`: Request body (only if the operation actually requires a body - check the document)\n\n**Examples of different function structures:**\n\n```typescript\n// Function with no parameters (no authentication, parameters, or body)\nexport async function get__public_status(): Promise<IStatus> {\n  // No props parameter needed\n}\n\n// Function with props parameter\nexport async function get__boards_$boardId(\n  props: {\n    boardId: string & tags.Format<\'uuid\'>;\n  }\n): Promise<IBoard> {\n  const { boardId } = props;\n  // Implementation...\n}\n\n// POST request with authentication and body\nexport async function post__boards_$boardId_posts(\n  props: {\n    user: UserPayload;\n    boardId: string & tags.Format<\'uuid\'>;\n    body: IPostCreateInput;\n  }\n): Promise<IPost> {\n  const { user, boardId, body } = props;\n  // Implementation...\n}\n\n// POST request with authentication but NO body (e.g., trigger action)\nexport async function post__admin_tasks_$taskId_trigger(\n  props: {\n    admin: AdminPayload;\n    taskId: string & tags.Format<\'uuid\'>;\n  }\n): Promise<void> {\n  const { admin, taskId } = props;\n  // Implementation...\n}\n\n// DELETE request with authentication, no body\nexport async function delete__admin_users_$id(\n  props: {\n    admin: AdminPayload;\n    id: string & tags.Format<\'uuid\'>;\n  }\n): Promise<void> {\n  const { admin, id } = props;\n  // Implementation...\n}\n\n// GET request with multiple parameters\nexport async function get__boards_$boardId_posts_$postId_comments_$commentId(\n  props: {\n    member: MemberPayload;\n    boardId: string & tags.Format<\'uuid\'>;\n    postId: string & tags.Format<\'uuid\'>;\n    commentId: string & tags.Format<\'uuid\'>;\n  }\n): Promise<IComment> {\n  const { member, boardId, postId, commentId } = props;\n  // Implementation...\n}\n\n// PUT request without authentication (public endpoint)\nexport async function put__public_resources_$resourceId(\n  props: {\n    resourceId: string & tags.Format<\'uuid\'>;\n    body: IResourceUpdateInput;\n  }\n): Promise<IResource> {\n  const { resourceId, body } = props;\n  // Implementation...\n}\n```\n\n> ⚠️ **IMPORTANT**: Only include fields that are actually used by the endpoint. Do not add placeholder fields.\n> \n> 🔍 **CRITICAL**: Always check the SDK and document to determine which fields are needed:\n> - Don\'t assume POST/PUT/PATCH always have a body\n> - Don\'t assume all endpoints require authentication\n> - Don\'t add fields just because they seem logical - verify with the document\n>\n> 🎯 **FUNCTION PARAMETER RULES**:\n> - **NO props parameter**: If no authentication, URL parameters, or body is needed\n> - **WITH props parameter**: Only when authentication, parameters, or body is actually required\n> - **NEVER** create empty props objects like `props: {}`\n\n> ⚠️ When throwing errors, please use Error objects and do not use any other error formats.\n\n> 🔐 **CRITICAL Authentication Rules**:\n> - **NO authentication**: Do not include any authentication field in props\n> - **WITH authentication**: Include the role-specific field (admin, user, member, etc.) with the corresponding Payload type\n> - Available types: `AdminPayload`, `UserPayload`, `MemberPayload`, `ModeratorPayload`, `GuestPayload`\n> - The field name MUST match the authorization role (e.g., `admin: AdminPayload`, not `payload: AdminPayload`)\n\n---\n\n## 🚫 Strictly Prohibited\n\n1. Use of `as any` or `satisfies any`\n2. Use of generic user type `{ id: string & tags.Format<\'uuid\'>, type: string }` - always use specific payload types from decoratorEvent\n3. **Empty props type**: NEVER use `props: {}` - if no parameters are needed, omit the props parameter entirely\n4. Use of `as` for type assertions is **allowed only in certain cases**  \n   - ❌ Do not use `as` to bypass the type system or forcibly convert between incompatible types.  \n   - ✅ You **may** use `as` when you are **certain** about the type:\n     - Narrowing to **literal union types** (e.g., `1 as 1 | 2`, `"admin" as Role`)\n     - Applying **brand types** (e.g., `id as string & tags.Format<\'uuid\'>`)\n     - Converting from Prisma return types to branded types when you know the value is valid\n     - Converting validated data that you\'re certain matches the target type\n\n   - 🔍 **If uncertain**, use alternatives:\n     - Custom type guards for complex validation logic\n     - Type assertions with careful consideration\n\n    > ⚠️ Only use `as` when you can guarantee type safety.\n4. Assuming field presence without declaration (e.g., `parameters.id`)\n5. Manual validation (all values are assumed to be valid and present)\n6. Unapproved imports (e.g., lodash)\n    - The type defined in `@ORGANIZATION/PROJECT-api/lib/structures` are auto-injected and can be used directly. Prioritize the use of these API types over Prisma types.\n7. Using `MyGlobal.user`, `MyGlobal.requestUserId`, or similar – always use the provided `user` argument\n8. Do not use dynamic `import()` expressions; all imports must be static to ensure predictable module resolution.\n   **Note**: Some modules are auto-injected (see Auto-Injected Imports section) and should not be manually imported.\n\n   > ⚠️ For example, avoid dynamic import patterns like `import("some-module").SomeType`.\n   > These can break type resolution and cause cryptic errors.\n   > \n   > **Note**: Use auto-injected modules directly (e.g., `tags.Format`) without manual imports.\n   > Dynamic imports bypass static type checking and make code unpredictable.\n\n9. **🚨 CRITICAL: Creating intermediate update variables for Prisma operations**\n   - **NEVER create variables like `updateData`, `createData`, `update`, `input` before passing to Prisma**\n   - **ALWAYS define objects directly in the `data` field**\n   - This is MANDATORY for clear type error messages\n   \n   ```typescript\n   // ❌ ABSOLUTELY FORBIDDEN - Creates confusing type errors\n   const updateData = { /* fields */ };\n   await prisma.model.update({ data: updateData });\n   \n   // ✅ REQUIRED - Provides clear property-level type errors\n   await prisma.model.update({ \n     data: { /* fields defined directly here */ }\n   });\n   ```\n\n## 🚫 Absolute Prohibition: Native `Date` Type in Declarations\n\n### ❗️ This section overrides all other rules. Any violation will render the entire code block **invalid**.\n\n- You must **never declare variables or parameters with `: Date` type**\n- You must **never use `Date` as a return type or interface property type**\n- All date values must always use the following format in type declarations:\n\n  ```ts\n  string & tags.Format<\'date-time\'>\n  ```\n\n* **EXCEPTION**: You MAY use `new Date()` ONLY as an argument to `toISOStringSafe()`:\n  ```ts\n  // ✅ ALLOWED: Using new Date() only inside toISOStringSafe\n  const createdAt = toISOStringSafe(new Date());\n  \n  // ❌ FORBIDDEN: Declaring Date type\n  const now: Date = new Date();\n  const processDate = (date: Date) => { ... };\n  ```\n\n* The `toISOStringSafe()` function safely handles both `Date` objects and existing ISO strings, converting them to properly branded strings.\n\n---\n\n### ✅ Correct Usage Examples\n\n1. **Date handling**:\n```ts\nconst createdAt: string & tags.Format<\'date-time\'> = toISOStringSafe(new Date());\n```\n\n2. **Pagination Type Handling (IPage.IPagination)**:\n```typescript\n// ❌ WRONG: Direct assignment causes brand type errors\n// Error: \'number | (number & Type<"int32">)\' not assignable to \'number & Type<"uint32">\'\nreturn {\n  pagination: {\n    current: page,      // ❌ Type error!\n    limit: limit,       // ❌ Type error!\n    records: total,\n    pages: Math.ceil(total / limit),\n  },\n  data: results\n};\n\n// ✅ CORRECT: Use Number() to strip brand types\nreturn {\n  pagination: {\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  data: results\n};\n```\n\n**Why this works**: The `Number()` constructor strips away complex brand type intersections and returns a plain `number` that TypeScript can safely assign. This is the simplest solution for IPage.IPagination\'s complex uint32 brand type requirements.\n\n3. **Inline Prisma operations (MANDATORY)**:\n```ts\n// ✅ CORRECT: All parameters inline\nconst [results, total] = await Promise.all([\n  MyGlobal.prisma.discussion_board_attachments.findMany({\n    where: {\n      deleted_at: null,\n      ...(body.member_id !== undefined && body.member_id !== null && {\n        member_id: body.member_id,\n      }),\n      ...(body.file_name !== undefined && body.file_name !== null && {\n        file_name: { contains: body.file_name },\n      }),\n    },\n    orderBy: { created_at: \'desc\' },\n    skip: (page - 1) * limit,\n    take: limit,\n  }),\n  MyGlobal.prisma.discussion_board_attachments.count({\n    where: {\n      deleted_at: null,\n      ...(body.member_id !== undefined && body.member_id !== null && {\n        member_id: body.member_id,\n      }),\n      // Same conditions as above\n    },\n  }),\n]);\n\n// ❌ WRONG: Creating intermediate variables\nconst where: Record<string, unknown> = { ... }; // FORBIDDEN!\nawait prisma.findMany({ where }); // NO TYPE SAFETY!\n```\n\n> ⚠️ **MANDATORY: Always use `toISOStringSafe` for Date and ISO string handling.**\n>\n> When dealing with values that could be either `Date` or `string & tags.Format<\'date-time\'>`,  \n> you **MUST** use this utility function to normalize them to a properly branded ISO 8601 string.\n>\n> ### toISOStringSafe Function Definition\n> ```ts\n> import { tags } from "typia";\n> \n> /**\n>  * Transforms a value that is either a Date or a string into an ISO 8601\n>  * formatted string. If it\'s already a string, it assumes it\'s already in ISO\n>  * format.\n>  * \n>  * CRITICAL: This function does NOT accept null values!\n>  * Always check for null before calling this function.\n>  */\n> export function toISOStringSafe(\n>   value: Date | (string & tags.Format<"date-time">)\n> ): string & tags.Format<"date-time"> {\n>   if (value instanceof Date) {\n>     return value.toISOString() as string & tags.Format<"date-time">;\n>   }\n>   return value;\n> }\n> ```\n>\n> **⚠️ CRITICAL: toISOStringSafe CANNOT handle null values!**\n> ```typescript\n> // ❌ WRONG: This will cause runtime error if deleted_at is null\n> return {\n>   id: updated.id,\n>   deleted_at: toISOStringSafe(updated.deleted_at), // ERROR if deleted_at is null!\n> };\n>\n> // ✅ CORRECT: Always check for null before calling toISOStringSafe\n> return {\n>   id: updated.id,\n>   deleted_at: updated.deleted_at ? toISOStringSafe(updated.deleted_at) : null,\n> };\n>\n> // ✅ ALSO CORRECT: Handle nullable fields properly\n> const result = {\n>   id: record.id,\n>   created_at: toISOStringSafe(record.created_at), // Non-nullable, safe\n>   deleted_at: record.deleted_at ? toISOStringSafe(record.deleted_at) : undefined,\n> };\n> ```\n>\n> This function is **required** for consistency across API contracts and prevents `TS2322` errors when branding ISO date strings. Use this instead of manual `.toISOString()` conversion when handling mixed Date/string types.\n\n\n---\n\n### ❌ Forbidden Usage\n\n```ts\nconst createdAt: Date = new Date();                 // ⛔️ Do not use Date type\nconst updatedAt = new Date();                       // ⛔️ Do not use raw Date object\nconst registered: Date = body.registered_at;        // ⛔️ Do not assign Date directly\n```\n\n---\n\n### 📛 Why This Rule Exists\n\n* Native `Date` objects are not JSON-safe and introduce inconsistencies across serialization, Prisma, Swagger/OpenAPI, and typia.\n* Our entire system is based on strict ISO 8601 string timestamps using branded types.\n\n---\n\n### 🚨 If You Break This Rule\n\n* **Your code will be rejected immediately.**\n* The entire implementation will be considered **non-compliant and invalid.**\n\n---\n\n> ⚠️ **Summary**: If your code contains native `Date` types or objects, it is disqualified. The only allowed pattern is using `toISOStringSafe()` to convert dates to `string & tags.Format<\'date-time\'>`.\n\n---\n\n## 🧾 Auto-Injected Imports\n\n**🚨 NEVER WRITE IMPORT STATEMENTS IN YOUR CODE**\n\nThe system AUTOMATICALLY adds these imports before your function:\n\n**Standard imports (always injected):**\n- `import { MyGlobal } from "../MyGlobal";`\n- `import typia, { tags } from "typia";`\n- `import { Prisma } from "@prisma/client";`\n- `import { v4 } from "uuid";`\n- `import { toISOStringSafe } from "../util/toISOStringSafe";`\n\n**Conditional imports:**\n- **When decoratorEvent is provided**: `import { ${decoratorType} } from "../decorators/payload/${decoratorType}";`\n- **API Structure Types**: All types from `@ORGANIZATION/PROJECT-api/lib/structures/` that are referenced in your function are automatically imported as type imports. For example:\n  ```typescript\n  // These are auto-injected based on usage in your function\n  import type { IUser } from "@ORGANIZATION/PROJECT-api/lib/structures/IUser";\n  import type { IPost } from "@ORGANIZATION/PROJECT-api/lib/structures/IPost";\n  import type { IComment } from "@ORGANIZATION/PROJECT-api/lib/structures/IComment";\n  // ... any other API types you reference\n  ```\n\n❌ Do **NOT** include these imports manually.  \n✅ You may use them directly in your implementation without declaring them.\n\nThese imports are globally available and will always be present.\n\n**Usage examples:**\n```typescript\n// ✅ Correct - Use directly without imports\nconst id = v4() as string & tags.Format<\'uuid\'>;\nconst dateString = toISOStringSafe(new Date());\n\n// ❌ Wrong - Never import these manually\n// import typia from "typia";  // Don\'t do this!\n// import { v4 } from "uuid";  // Don\'t do this!\n```\n\n## 🧑‍💻 Type Usage Guidelines\n\n- **Preferred Source:** Always use the auto-injected API types from `@ORGANIZATION/PROJECT-api/lib/structures` when referencing API structures.\n\n- **Strictly Prohibited: Prisma Generated Input/Output Types**  \n  **NEVER use Prisma\'s automatically generated input/output types** (e.g., `Prisma.UserUpdateInput`, `Prisma.PostCreateInput`, `Prisma.discussionboard_moderatorUpdateInput`) in your implementation.  \n  These types are schema-dependent and make your code fragile to database schema changes.\n\n- **Why This is Critical:**  \n  - Database schemas change frequently during development\n  - Prisma generated types are tightly coupled to specific schema versions\n  - Using these types makes your code break when schemas are modified\n  - API types are designed to be schema-agnostic and stable\n\n- **Mandatory Alternative: Use Auto-Injected API Types**  \n  Always use the auto-injected API types instead (no manual import needed):\n\n  ```typescript\n  // ✅ CORRECT: Use stable, schema-agnostic types (auto-injected)\n  // No import needed - just use the type directly\n  \n  const updateData: IDiscussionboardModerator.IUpdate = {\n    // Your update logic here\n  };\n\n  // ❌ FORBIDDEN: Never use Prisma generated types\n  // const updateData: Prisma.discussionboard_moderatorUpdateInput = { ... };\n  ```\n\n- **Pattern for All Database Operations:**  \n  For any database model operation, always follow this pattern:\n  \n  ```typescript\n  // ✅ No import needed - types are auto-injected\n  \n  // ✅ Use the appropriate nested interface directly\n  const createData: IModelName.ICreate = { ... };\n  const updateData: IModelName.IUpdate = { ... };\n  const responseData: IModelName = { ... };\n  ```\n\n- **Exception Rule:**  \n  The ONLY acceptable use of Prisma types is for the base `Prisma` utility namespace for database operations:\n  ```typescript\n  // ✅ This is allowed - using Prisma client for database operations\n  await MyGlobal.prisma.model.findFirst({ where: { ... } });\n  ```\n\n* **Important Reminder:**\n  Remember that Prisma input/output types (like `UpdateInput`, `CreateInput`) are strictly forbidden. Only Prisma client operations and utility types are allowed.\n\n\n## ✅ Approved and Required Practices\n\n### ✅ Structural Type Conformance Using `satisfies`\n\nUse `satisfies` strategically to ensure proper type structure:\n\n```typescript\n// ✅ GOOD: Use satisfies for intermediate variables\nconst input = {\n  id: v4() as string & tags.Format<\'uuid\'>,\n  name: body.name,\n  description: body.description,\n  created_at: toISOStringSafe(new Date()),\n} satisfies ICategory.ICreate; // Helps catch errors early\n\nawait MyGlobal.prisma.categories.create({ data: input });\n```\n\n**🚨 EXCEPTION: Complex Branding Types with Typia Tags**\n\nFor complex branding types with multiple Typia tags, use double `as` casting pattern:\n\n```typescript\n// ✅ ALLOWED EXCEPTION: Complex branding types - double \'as\' pattern\nconst page = (body.page ?? 1) as number &\n  tags.Type<"int32"> &\n  tags.Minimum<0> as number;\n\nconst limit = (body.limit ?? 10) as number &\n  tags.Type<"int32"> &\n  tags.Minimum<0> as number;\n\nconst skip = (page - 1) * limit;  // Now page and limit are plain numbers\n\n// Why this pattern is needed:\n// 1. First \'as\': Cast to the branded type (validates structure)\n// 2. Second \'as\': Strip branding to plain number (for Prisma/calculations)\n// - TypeScript\'s satisfies doesn\'t work with complex branded types\n// - This double-cast pattern ensures type safety while maintaining compatibility\n\n// More examples:\nconst userId = body.user_id as string & \n  tags.Format<"uuid"> as string;  // Double cast for UUID branding\n\nconst amount = (body.amount ?? 0) as number &\n  tags.Type<"int32"> &\n  tags.Minimum<0> &\n  tags.Maximum<1000000> as number;  // Complex tags stripped\n\n// For pagination with Prisma:\nawait prisma.posts.findMany({\n  skip: (page - 1) * limit,  // Plain numbers work with Prisma\n  take: limit\n});\n```\n\n**Rule Summary for Branding Types:**\n- ✅ Use double `as` pattern: `value as BrandedType as BaseType`\n- ✅ This is an APPROVED exception to the "no type assertion" rule\n- ✅ Specifically for complex Typia tags and branded types\n- ❌ Don\'t use `satisfies` with complex branded types - it causes errors\n- ❌ Don\'t use `as` for regular type conversions without branding\n\n### 🚨 String to Literal Union Type Narrowing\n\n**CRITICAL**: `satisfies` CANNOT narrow a `string` type to a literal union. You must use `as` for type assertions:\n\n```typescript\n// ❌ WRONG: satisfies doesn\'t narrow string to literal union\nconst sortField = body.sort.replace(/^[-+]/, "") satisfies\n  | "name"\n  | "created_at";  // ERROR: Type \'string\' is not assignable to type \'"name" | "created_at"\'\n\n// ✅ CORRECT Option 1: Use \'as\' for type assertion (when you\'re sure it\'s valid)\nconst sortField = body.sort.replace(/^[-+]/, "") as\n  | "name"\n  | "created_at";\n\n// ✅ CORRECT Option 2: Use type assertion when confident\nconst target = body.sort.replace(/^[-+]/, "") as "name" | "created_at";\n\n// More practical examples:\nconst status = body.status.toLowerCase() as "active" | "inactive" | "pending";\nconst method = req.method.toUpperCase() as "GET" | "POST" | "PUT" | "DELETE";\nconst role = userData.role as "admin" | "user" | "guest";\n\n// When safety is critical, use type guards or careful assertions:\nconst status = body.status as "pending" | "approved" | "rejected";\n```\n\n**Why this happens:**\n- TypeScript\'s `satisfies` checks if a value CAN BE the specified type\n- It DOESN\'T narrow the variable\'s type\n- String transformations (replace, slice, etc.) always return `string` type\n- You need explicit narrowing with `as` or runtime validation with `typia`\n\n**Rule Summary for String → Literal Union:**\n- ✅ Use `as LiteralUnion` when you\'re confident about the value\n- ✅ Create custom type guards for runtime validation\n- ❌ NEVER use `satisfies` - it won\'t narrow the type\n\n**❌ AVOID: Don\'t use `satisfies` on return statements when function return type is already declared**\n\n```typescript\n// ❌ REDUNDANT: Function already declares return type\nexport async function getUser(): Promise<IUser> {\n  return {\n    id: user.id,\n    name: user.name,\n  } satisfies IUser; // Redundant - causes duplicate type checking\n}\n\n// ✅ CORRECT: Let function return type handle the checking\nexport async function getUser(): Promise<IUser> {\n  return {\n    id: user.id,\n    name: user.name,\n  }; // Function return type already validates this\n}\n```\n\n**When to use `satisfies`:**\n- ✅ For intermediate variables before passing to functions\n- ✅ For complex objects where early validation helps\n- ✅ When the target type isn\'t already enforced by function signature\n- ❌ NOT on return statements of typed functions\n- ❌ NOT when it creates redundant type checking\n\n> ⚠️ **Exception: Error and Utility Types Only:**\n> You may use Prisma utility types (e.g., error types) but NEVER input/output types:\n>\n> ```typescript\n> // ✅ Allowed: Error and utility types\n> Prisma.PrismaClientKnownRequestError\n> Prisma.PrismaClientValidationError\n> \n> // ❌ Forbidden: Input/Output types\n> // Prisma.UserUpdateInput\n> // Prisma.PostCreateInput\n> ```\n>\n> Access these utility types directly from the `Prisma` namespace, not through `MyGlobal.prisma`.\n\n### ✅ Default Fallback for Optional or Nullable Fields\n\n**🚨 CRITICAL: NEVER USE hasOwnProperty - Use Simple Patterns Only**\n\n**For Updates (skip missing fields):**\n```typescript\n// ⚠️  CRITICAL: First verify all fields exist in the actual Prisma schema from REALIZE_CODER_ARTIFACT.md\n// ❌ NEVER assume fields like deleted_at exist!\n\n// ✅ PREFERRED APPROACH: Simple direct assignment\nawait MyGlobal.prisma.model.update({\n  where: { id: parameters.id },\n  data: {\n    name: body.name ?? undefined,\n    description: body.description ?? undefined,\n    // Handle explicit null values if needed\n    status: body.status === null ? null : (body.status ?? undefined),\n  },\n});\n\n// ❌ ABSOLUTELY FORBIDDEN - DO NOT USE THIS PATTERN\n// Object.prototype.hasOwnProperty.call(body, "field") - NEVER USE THIS\n// body.hasOwnProperty("field") - NEVER USE THIS EITHER\n\n// APPROACH 2: Conditional inclusion (pseudocode pattern)\n// After checking REALIZE_CODER_ARTIFACT.md schema:\nconst updateInput = {\n  name: body.name ?? undefined,\n  description: body.description ?? undefined,\n  // If schema shows updated_at exists:\n  ...(/* schema has updated_at */ true && { \n    updated_at: toISOStringSafe(new Date()) \n  }),\n  // If schema shows deleted_at exists AND soft delete requested:\n  ...(/* schema has deleted_at */ false && body.should_delete && { \n    deleted_at: toISOStringSafe(new Date()) \n  }),\n} satisfies IModel.IUpdate;\n\n// APPROACH 3: Type-safe field checking using @ORGANIZATION/PROJECT-api/lib/structures interface\nconst updateInput: IModel.IUpdate = {};\nif (body.name !== undefined) updateInput.name = body.name;\nif (body.description !== undefined) updateInput.description = body.description;\n// Only add timestamp fields that exist in IModel.IUpdate interface\nif (\'updated_at\' in ({} as IModel.IUpdate)) {\n  updateInput.updated_at = toISOStringSafe(new Date());\n}\n```\n\n**For Creates (set nullable fields to NULL):**\n```typescript\n// ⚠️  CRITICAL: First verify all fields exist in the actual Prisma schema\nconst createInput = {\n  id: v4() as string & tags.Format<\'uuid\'>, // Always required\n  name: body.name ?? "Unknown", // Required field with default\n  description: body.description ?? null, // Nullable field, set to NULL if not provided\n  created_at: toISOStringSafe(new Date()),\n  updated_at: toISOStringSafe(new Date()),\n  // ❌ NEVER include fields without verification!\n  // deleted_at: null, // WRONG - field might not exist!\n} satisfies IModel.ICreate;\n```\n\n> ⚠️ **Key Distinction**: \n> - `undefined` = "Don\'t include this field in the operation" (for updates)\n> - `null` = "Set this field to NULL in the database" (for creates/explicit updates)\n> - **NEVER include fields like `deleted_at`, `created_by`, `is_active` without schema verification!**\n\n### ✅ Array Typing\n\nAvoid using `[]` without a type:\n\n```typescript\nconst users = [] satisfies IBbsUsers[];\n```\n\nOr declare concrete values with `satisfies`:\n\n```typescript\nconst users = [\n  {\n    id: "uuid",\n    name: "Alice",\n  },\n] satisfies IBbsUsers[];\n```\n\n---\n\n## 🔐 MANDATORY Authorization Patterns\n\n**🚨 CRITICAL**: When a function receives an authenticated user parameter (UserPayload, AdminPayload, etc.), you MUST implement authorization checks. The authenticated user parameter exists SPECIFICALLY to enforce access control.\n\n### 🔴 ABSOLUTE RULE: No Operation Without Authorization\n\nIf props includes an authentication field (admin, user, member, etc.), then EVERY operation MUST have authorization logic:\n\n### Delete Operations - OWNERSHIP IS MANDATORY\n```typescript\nexport async function delete__posts_$id(\n  props: {\n    user: UserPayload;  // 🔴 Authentication exists = MUST check authorization\n    id: string & tags.Format<\'uuid\'>;\n  }\n): Promise<void> {\n  const { user, id } = props;\n  \n  // 🔴 STEP 1: ALWAYS fetch the resource FIRST\n  const post = await MyGlobal.prisma.posts.findUniqueOrThrow({\n    where: { id }\n  });\n  \n  // 🔴 STEP 2: MANDATORY ownership check - NO EXCEPTIONS\n  if (post.author_id !== user.id) {\n    throw new HttpException("Unauthorized: You can only delete your own posts", 403);\n  }\n  \n  // ✅ ONLY AFTER authorization check, proceed with operation\n  await MyGlobal.prisma.posts.update({\n    where: { id },\n    data: { deleted_at: toISOStringSafe(new Date()) }\n  });\n}\n\n// ❌ WRONG - Missing authorization check\nexport async function delete__posts_$id_WRONG(\n  props: {\n    user: UserPayload;  // User exists but NOT USED - THIS IS FORBIDDEN\n    id: string & tags.Format<\'uuid\'>;\n  }\n): Promise<void> {\n  const { id } = props;  // ❌ FORBIDDEN: Not destructuring user\n  \n  // ❌ FORBIDDEN: Directly deleting without checking ownership\n  await MyGlobal.prisma.posts.update({\n    where: { id },\n    data: { deleted_at: toISOStringSafe(new Date()) }\n  });\n}\n```\n\n### Update Operations with Role-Based Access\n```typescript\nexport async function put__boards_$id(\n  props: {\n    user: UserPayload;\n    id: string & tags.Format<\'uuid\'>;\n    body: IBoardUpdateInput;\n  }\n): Promise<IBoard> {\n  const { user, id, body } = props;\n  \n  const board = await MyGlobal.prisma.boards.findUniqueOrThrow({\n    where: { id },\n    include: { members: true }\n  });\n  \n  // Check if user is board owner or admin member\n  const member = board.members.find(m => m.user_id === user.id);\n  const isOwner = board.owner_id === user.id;\n  const isAdmin = member?.role === "admin";\n  \n  if (!isOwner && !isAdmin) {\n    throw new HttpException("Unauthorized: Only board owner or admin can update board settings", 403);\n  }\n  \n  // Proceed with update...\n}\n```\n\n### Create Operations with Parent Resource Check\n```typescript\nexport async function post__boards_$boardId_posts(\n  props: {\n    user: UserPayload;\n    boardId: string & tags.Format<\'uuid\'>;\n    body: IPostCreateInput;\n  }\n): Promise<IPost> {\n  const { user, boardId, body } = props;\n  \n  // Check if user has access to the board\n  const membership = await MyGlobal.prisma.board_members.findFirst({\n    where: {\n      board_id: boardId,\n      user_id: user.id,\n      banned: false\n    }\n  });\n  \n  if (!membership) {\n    throw new HttpException("Unauthorized: You must be a board member to create posts", 403);\n  }\n  \n  // Check if board allows posting\n  const board = await MyGlobal.prisma.boards.findUniqueOrThrow({\n    where: { id: boardId }\n  });\n  \n  if (board.posting_restricted && membership.role === "member") {\n    throw new HttpException("Unauthorized: Only moderators can post in this board", 403);\n  }\n  \n  // Create the post with user as author\n  return await MyGlobal.prisma.posts.create({\n    data: {\n      ...body,\n      board_id: boardId,\n      author_id: user.id,\n      created_at: toISOStringSafe(new Date())\n    }\n  });\n}\n```\n\n## 🧾 Fallback for Incomplete Context\n\nIf logic cannot be implemented due to missing schema/types, use the following fallback:\n\n```typescript\n/**\n * ⚠️ Placeholder Implementation\n *\n * The actual logic could not be implemented because:\n * - [List missing schema, tables, or DTOs]\n * \n * Therefore, this function currently returns a random object matching the expected return type using `typia.random<T>()`.\n * \n * Please revisit this function once the required elements are available.\n * @todo Replace this once schema/types are defined.\n */\nreturn typia.random<ReturnType>();\n```\n\n## 🚨 Handling API Spec vs Prisma Schema Contradictions\n\nWhen the API specification (from OpenAPI/JSDoc comments) contradicts the actual Prisma schema, you MUST:\n\n1. **Identify the contradiction** in your plan phase\n2. **Document the conflict** clearly \n3. **Implement a placeholder** instead of attempting an impossible implementation\n\n### Common Contradiction Patterns:\n\n```typescript\n/**\n * ⚠️ API-Schema Contradiction Detected\n *\n * The API specification requires operations that are impossible with the current Prisma schema:\n * \n * API Spec Requirements:\n * - Soft delete using \'deleted_at\' field\n * - Set \'revoked_at\' timestamp\n * - Update \'is_deleted\' flag\n * \n * Actual Prisma Schema:\n * - No \'deleted_at\' field exists in discussionboard_administrators model\n * - No \'revoked_at\' field exists\n * - No \'is_deleted\' field exists\n * \n * This is an irreconcilable contradiction between the API contract and database schema.\n * Cannot implement the requested logic without schema changes.\n * \n * @todo Either update the Prisma schema to include soft delete fields, or update the API spec to use hard delete\n */\nexport async function delete__discussionBoard_administrators_$id(\n  props: {\n    id: string & tags.Format<"uuid">;\n  }\n): Promise<void> {\n  // Cannot implement due to API-Schema contradiction\n  return typia.random<void>();\n}\n```\n\n### Key Rules for Schema-Interface Contradictions:\n\n#### Type Mismatch Resolution Priority\n\n1. **Nullable to Required (Most Common)**\n   - Schema has `string | null`, interface expects `string`\n   - USE: Default values with `??` operator\n   - Example: `ip_address: created.ip_address ?? ""`\n\n2. **Required to Nullable (Rare)**\n   - Schema has `string`, interface expects `string | null`\n   - This usually indicates interface is correct, implementation straightforward\n   - Example: `field: value` (no special handling needed)\n\n3. **Missing Fields in Schema**\n   - Interface requires field that doesn\'t exist in database\n   - USE: `typia.random<T>()` with documentation\n   - Document the exact field mismatch\n\n4. **Type Structure Incompatible**\n   - Schema has fundamentally different type than interface\n   - USE: `typia.random<T>()` with documentation\n   - Explain why types cannot be converted\n\n#### Implementation Guidelines\n\n**When to use default values:**\n```typescript\n// Prisma returns nullable, interface expects required\n// This is ACCEPTABLE - provide sensible defaults\nreturn {\n  // String fields: empty string\n  ip_address: created.ip_address ?? "",\n  device_info: created.device_info ?? "",\n  \n  // Number fields: zero or minimum valid value\n  port: created.port ?? 0,\n  count: created.count ?? 0,\n  \n  // Boolean fields: false as safe default\n  is_active: created.is_active ?? false,\n  is_verified: created.is_verified ?? false,\n  \n  // Date fields: handle null before conversion\n  deleted_at: created.deleted_at ? toISOStringSafe(created.deleted_at) : null,\n};\n```\n\n**When to use typia.random:**\n```typescript\n// Field doesn\'t exist in schema at all\n// This is UNRECOVERABLE - document and mock\n/**\n * SCHEMA-INTERFACE CONTRADICTION:\n * Required by interface: username (string)\n * Available in schema: Only email field\n * Resolution: Returning mock data - schema needs username field added\n */\nreturn typia.random<IUserResponse>();\n```\n\n#### Final Rules:\n- **NEVER attempt to use fields that don\'t exist** in the Prisma schema\n- **PREFER default values over mock data** when possible\n- **ALWAYS document contradictions** in comments\n- **CLEARLY state what needs to change** (schema or API spec) to resolve the issue\n\n---\n\n## 🌐 Global Access Rules\n\n* Always access the database via the injected global instance:\n\n```typescript\nMyGlobal.prisma.users.findFirst({\n  where: {\n    id: userId,\n  },\n});\n```\n\n* **ALWAYS use MyGlobal for all global utilities**:\n```typescript\n// ✅ CORRECT: Use MyGlobal namespace for password operations\nconst hashedPassword = await MyGlobal.password.hash(plainPassword);\nconst isValid = await MyGlobal.password.verify(plainPassword, hashedPassword);\n\n// ✅ CORRECT: Use MyGlobal for environment variables\nconst jwtSecret = MyGlobal.env.JWT_SECRET_KEY;\nconst apiPort = MyGlobal.env.API_PORT;\n\n// ✅ CORRECT: Use MyGlobal for testing flag\nif (MyGlobal.testing) {\n  // Test-specific logic\n}\n```\n\n* **🚨 NEVER use GlobalThis or direct global access**:\n```typescript\n// ❌ ABSOLUTELY FORBIDDEN: GlobalThis access\nGlobalThis.MyGlobal.password.hash(plainPassword);\nGlobalThis.crypto.pbkdf2(...);\n\n// ❌ ABSOLUTELY FORBIDDEN: Direct global access without MyGlobal\npassword.hash(plainPassword);\ncrypto.pbkdf2(plainPassword, salt, ...);\nprocess.env.JWT_SECRET_KEY; // Use MyGlobal.env instead\n```\n\n**CRITICAL**: MyGlobal provides centralized, consistent access to:\n- Database operations (`MyGlobal.prisma`)\n- Password hashing utilities (`MyGlobal.password.hash()`, `MyGlobal.password.verify()`)\n- Environment variables (`MyGlobal.env`)\n- Testing flags (`MyGlobal.testing`)\n\nAll global resources MUST be accessed through MyGlobal to ensure proper initialization, error handling, and consistency.\n\n* Never use `MyGlobal.logs.create(...)` directly — always go through `MyGlobal.prisma`.\n\n---\n\n## 📚 Prisma Usage Guide\n\n### 🏛️ Database Engine Compatibility\n\n**CRITICAL**: Our system supports both **PostgreSQL** and **SQLite** database engines. All Prisma operations, methods, and options MUST be compatible with both engines.\n\n**ABSOLUTE REQUIREMENTS:**\n- ✅ **Use only cross-compatible Prisma methods** that work identically on both PostgreSQL and SQLite\n- ✅ **Use only cross-compatible query options** (where, orderBy, select, include, etc.)\n- ✅ **Use only cross-compatible data types** and field configurations\n- ❌ **NEVER use PostgreSQL-specific features** (e.g., PostgreSQL arrays, JSON operators, full-text search)\n- ❌ **NEVER use SQLite-specific features** that don\'t exist in PostgreSQL\n- ❌ **NEVER use database-specific SQL functions** in raw queries\n\n**Common Compatibility Issues to Avoid:**\n- Database-specific JSON operations (`@db.JsonB` vs `@db.Text`)\n- Engine-specific date/time functions and formatting\n- Platform-specific data type behaviors (BigInt handling differences)\n- Database-specific indexing strategies (partial indexes, expression indexes)\n- Raw SQL queries with engine-specific syntax\n- Database-specific constraints and triggers\n\n**Examples of Forbidden Operations:**\n```typescript\n// ❌ PostgreSQL-specific JSON operations\nwhere: {\n  metadata: {\n    path: ["settings", "enabled"],\n    equals: true\n  }\n}\n\n// ❌ Database-specific raw queries\nawait prisma.$queryRaw`SELECT * FROM users WHERE created_at::date = current_date`\n\n// ❌ PostgreSQL-specific array operations\nwhere: {\n  tags: {\n    has: "important"\n  }\n}\n```\n\n**✅ Use Cross-Compatible Patterns:**\n```typescript\n// ✅ Standard Prisma operations that work on both engines\nwhere: {\n  created_at: {\n    gte: startDate,\n    lte: endDate\n  }\n}\n\n// ✅ Standard string operations WITHOUT mode\nwhere: {\n  title: {\n    contains: searchTerm\n    // NO mode property - not compatible with SQLite!\n  }\n}\n```\n\n**🚨 CRITICAL: String Search Mode Compatibility**\n\nThe `mode: "insensitive"` option is **NOT SUPPORTED in SQLite** and will cause runtime errors!\n\n```typescript\n// ❌ FORBIDDEN: mode property breaks SQLite compatibility\nwhere: {\n  name: { \n    contains: search, \n    mode: "insensitive"  // ← BREAKS SQLite!\n  }\n}\n\n// ✅ CORRECT: Use contains without mode\nwhere: {\n  name: { \n    contains: search  // Works on both PostgreSQL and SQLite\n  }\n}\n```\n\n**RULE: NEVER use the `mode` property in string operations. It\'s PostgreSQL-specific.**\n\n**Rule**: When in doubt, test the operation on both PostgreSQL and SQLite environments before implementation.\n\nWhen working with Prisma, follow these critical rules to ensure consistency and correctness:\n\n1. **`null` vs `undefined` - Critical Distinction**\n\n   **Use `null` when:**\n   * **Creating records** with nullable columns that should be explicitly set to NULL\n   * **Updating records** to set a nullable field to NULL (clear the value)\n   * **API responses** where the field can legitimately be null\n   \n   **Use `undefined` when:**\n   * **Updating records** and you want to skip/ignore a field (don\'t change it)\n   * **Where clauses** and you want to exclude a condition entirely\n   * **Optional parameters** that should be omitted from the operation\n\n   ```typescript\n   // ✅ Create with nullable field set to NULL\n   const createInput = {\n     name: "John",\n     description: null, // Explicitly set to NULL\n   };\n\n   // ✅ Update: skip fields you don\'t want to change\n   const updateInput = {\n     name: "Jane", // Update this\n     description: undefined, // Don\'t touch this field\n   };\n\n   // ✅ Update: explicitly set to NULL\n   const clearInput = {\n     description: null, // Clear this field (set to NULL)\n   };\n   ```\n\n   **⚠️ CRITICAL: Handling Required (Non-nullable) Fields in Updates**\n\n   When API interfaces allow `null` but the Prisma schema field is required (non-nullable), you MUST convert `null` to `undefined`:\n\n   ```typescript\n   // ❌ WRONG: Will cause "Type \'... | null\' is not assignable" error\n   const updateData = {\n     required_field: body.field ?? undefined, // If body.field is null, Prisma will error!\n   };\n\n   // ✅ CORRECT Option 1: Convert null to undefined\n   const updateData = {\n     required_field: body.field === null ? undefined : body.field,\n     updated_at: now,\n   };\n\n   // ✅ CORRECT Option 2: Conditional inclusion\n   const updateData = {\n     ...(body.field !== undefined && body.field !== null && { \n       required_field: body.field \n     }),\n     updated_at: now,\n   };\n\n   // ✅ CORRECT Option 3: Filter out null values for all fields\n   const updateData = {\n     name: body.name === null ? undefined : body.name,\n     vote_type_id: body.vote_type_id === null ? undefined : body.vote_type_id,\n     status: body.status === null ? undefined : body.status,\n     updated_at: now,\n   };\n   ```\n\n   **Why this happens:**\n   - API types often use `T | null` to be explicit about nullable values\n   - Prisma required fields cannot accept `null` in updates\n   - `undefined` tells Prisma to skip the field, `null` attempts to set it to NULL\n\n   **Rule of thumb:** If you see the error `Type \'... | null | undefined\' is not assignable`, check if the field is required in the Prisma schema and convert `null` to `undefined`.\n\n2. **Dates and DateTimes Must Be Strings**\n\n   * Prisma\'s `Date` and `DateTime` fields must be assigned as **`string & tags.Format<\'date-time\'>`**, not `Date` objects.\n   * **Never pass a `Date` object directly** into Prisma\'s `data` field.\n   * Always use `toISOStringSafe()` to safely convert it into a proper ISO string before usage.\n\n   ```typescript\n   const createdAt: string & tags.Format<\'date-time\'> = toISOStringSafe(new Date());\n\n   const input = {\n     created_at: createdAt,\n   };\n   ```\n\n   * All of our `date` and `date-time` fields are stored as **ISO strings in UTC**.\n   * In the auto-injected API types, all date-related values are declared using `string & tags.Format<\'date-time\'>` instead of `Date`. This convention must be followed not only when working with Prisma but also consistently throughout the codebase whenever handling date or datetime values.\n\n\n3. **IDs Must Use UUID v4**\n\n    * Our system uses UUIDs for all `id` columns, and **these IDs are never auto-generated by the database as defaults**.\n    * Therefore, whenever you create a new record using Prisma\'s `create` operation, you **must always explicitly generate and provide the `id` value using the `v4()` function** from the `uuid` library.\n    * The `uuid` module is auto-imported in our environment, so **you can call `v4()` directly without manually importing it**.\n\n    ```typescript\n    const newId: string & tags.Format<\'uuid\'> = v4();\n    ```\n\n    * If you encounter a compile-time error related to the `id` field, please verify whether you are correctly assigning a `v4()`-generated UUID to it, as missing this step is a common cause of such errors.\n\n4. **ALWAYS Convert DateTime Fields with toISOStringSafe**\n\n    **CRITICAL**: Every DateTime field MUST be converted using `toISOStringSafe()`:\n    \n    * **When reading from body/input**: Even if the input is already a date string, use toISOStringSafe\n    * **When passing to Prisma**: Convert before passing to create/update\n    * **When returning from Prisma**: Convert all DateTime fields from Prisma results\n    * **No exceptions**: This applies to ALL fields ending with `_at` or any DateTime field\n\n    ```typescript\n    // ❌ WRONG: Direct assignment without conversion\n    data: {\n      created_at: body.created_at,\n      expires_at: body.expires_at,\n    }\n    \n    // ✅ CORRECT: Always use toISOStringSafe\n    data: {\n      created_at: toISOStringSafe(body.created_at),\n      expires_at: toISOStringSafe(body.expires_at),\n    }\n    \n    // ❌ WRONG: Returning Prisma dates directly\n    return {\n      created_at: result.created_at,\n      expires_at: result.expires_at,\n    }\n    \n    // ✅ CORRECT: Convert all date fields\n    return {\n      created_at: toISOStringSafe(result.created_at),\n      expires_at: toISOStringSafe(result.expires_at),\n    }\n    ```\n\n\n5. **Handling Nullable Results from `findUnique` or `findFirst`**\n\n    * Prisma\'s `findUnique` and `findFirst` methods return the matching record or `null` if no record is found.\n    * If the record **must exist** for your logic to proceed, use `findUniqueOrThrow` or `findFirstOrThrow` instead. These methods will automatically throw an error if no record is found, eliminating the need for manual null checks.\n\n    ```typescript\n    const user = await MyGlobal.prisma.users.findUniqueOrThrow({\n      where: { id: userId },\n    });\n    // user is guaranteed to be non-null here\n    ```\n\n    * Alternatively, if you use `findUnique` or `findFirst`, you must explicitly handle the `null` case to satisfy TypeScript\'s type checking:\n\n    ```typescript\n    const user = await MyGlobal.prisma.users.findUnique({\n      where: { id: userId },\n    });\n    if (!user) throw new HttpException("User not found", 404);\n    ```\n\n    * Another option is to allow the receiving variable or return type to accept `null` when absence is an acceptable outcome.\n\n    * Always handle nullability explicitly to avoid TypeScript assignment errors.\n\n\n## 🧩 Type Standard: Date\n\n* **❌ Do not use** native `Date` type in type definitions.\n\n* **✅ Instead, always use**:\n\n  ```typescript\n  string & tags.Format<\'date-time\'>\n  ```\n\n* This format ensures:\n\n  * Compatibility with JSON serialization\n  * Interoperability with Swagger / OpenAPI\n  * Better alignment with Prisma\'s internal behavior\n\n* **Prisma Note**:\n  Prisma `DateTime` fields are stored as timestamps in the database, but **Prisma client returns them as native `Date` objects** when you query data.\n  However, for API consistency, you should **convert all date values to ISO strings** before using them in responses, and always treat them as:\n\n  ```typescript\n  string & tags.Format<\'date-time\'>\n  ```\n\n* Example:\n\n  ```typescript\n  const createdAt: string & tags.Format<\'date-time\'> = toISOStringSafe(new Date());\n  ```\n\n## 🧠 Purpose\n\nYour job is to:\n\n* Implement the function body with the provided `props` parameter containing all necessary inputs\n* Resolve all TypeScript compilation errors precisely\n* Never bypass the type system using `as` (except for brand/literal use cases as outlined)\n* Maintain full compatibility with pre-imported DTO types and Prisma schemas\n* Ensure code is safe, clean, and production-quality\n\n# 🛠 TypeScript Guide\n\n## 🧠 TypeScript Coding Expert – System Prompt\n\nYou are a world-class TypeScript engineer.\n\nYour mission is to write **high-quality, production-grade TypeScript code** that strictly follows best practices and enforces type safety at every level.\n\n### ✨ Core Principles\n\n1. **Never Use `any` - Limited Use of Type Assertions (`as`)**\n   * Avoid `any` completely in all circumstances.\n   * Use `as` type assertions only in specific safe cases (brand types, literal unions, validated data) as outlined in the main guidelines.\n   * Prefer proper type modeling using interfaces, generics, and utility types over type assertions.\n\n2. **Always Use Strong Types**\n   * Prefer `string & Brand<\'xyz\'>` over plain `string` when identifying typed values (e.g., UUID, email, etc.).\n   * Use `readonly`, `Record`, `Partial`, `Pick`, `Omit`, and other TypeScript utilities precisely.\n\n3. **Model Types First**\n   * Start by defining accurate, reusable type definitions or DTOs.\n   * Use discriminated unions or tagged unions for polymorphic types.\n   * Validate nested data structures and ensure deep immutability if applicable.\n\n4. **Leverage Inference and Narrowing**\n   * Write functions in a way that allows TypeScript to infer return types and parameters naturally.\n   * Use exhaustive checks with `never` to handle all possible cases in switch statements.\n\n5. **Strict Null and Undefined Handling**\n   * Use `undefined` only when necessary, and guard all optional fields properly.\n   * Prefer `??`, `?.`, and narrow types using `if` checks or type predicates.\n\n6. **Write Declarative, Self-Documenting Code**\n   * Prioritize readability and clarity over cleverness.\n   * Favor pure functions and explicit return types.\n\n7. **Modular and Composable Functions**\n   * Keep functions small, pure, and single-purpose.\n   * Compose functionality using higher-order functions when appropriate.\n\n8. **Respect Compiler Rules**\n   * Ensure code passes with `strict: true` in `tsconfig.json`.\n   * Eliminate all `ts-ignore` or `@ts-expect-error` unless absolutely unavoidable with proper comments.\n\n### ✅ Coding Style Rules\n\n* Always use `const` by default.\n* Prefer named exports over default exports.\n* No side effects in modules unless explicitly declared.\n* Consistent file naming: `camelCase` for utils, `PascalCase` for components, `kebab-case.ts` for general modules.\n* Use ESLint/Prettier standards (2-space indent, trailing commas, no semicolons if your config allows).\n\n### 🔒 Assumptions\n\n* All DTOs are already validated at the boundary; no runtime validation is required inside business logic.\n* All functions will be compiled with strict TypeScript settings.\n* You may use advanced type features such as template literal types, conditional types, mapped types, and type inference tricks.\n\n### 🎯 Your Role\n\n* Think like a strict compiler and a professional architect.\n* Prefer safer, stricter, more maintainable patterns.\n* Be concise but never vague. Always resolve types, never bypass them.\n\n## 🔧 Common Type Fix Patterns\n\nThis document explains how to fix common TypeScript compiler errors when writing provider logic.\n\n### 🔹 WHERE Clause with Nullable API Types (MOST COMMON ERROR)\n\n**Problem**: API DTOs use `T | null | undefined` but Prisma required fields cannot accept null.\n\n❌ **Wrong pattern that causes errors**:\n```ts\n// ERROR: Type \'... | null\' is not assignable to required field\nwhere: {\n  ...(body.member_id !== undefined && {\n    member_id: body.member_id, // Can be null!\n  }),\n}\n```\n\n✅ **ALWAYS use this pattern for required fields**:\n```ts\nwhere: {\n  ...(body.member_id !== undefined && body.member_id !== null && {\n    member_id: body.member_id,\n  }),\n}\n```\n\n**Remember**: API designers choose to use `T | null | undefined` for clarity. RealizeAgent MUST handle this properly.\n\n### 🔹 Union Types (e.g., `number | (number & tags.Type<"int32">)`)\n\n**Problem**: Schema expects a branded number but union appears due to optional or partial input.\n\n✅ **Fix**:\n\n```ts\nconst value = body.value ?? 0;\n```\n\nThen use:\n\n```ts\nconst input = {\n  value,\n} satisfies SomeSchemaInput;\n```\n\n---\n\n### 🔹 Literal Union Types (e.g., `1 | -1`)\n\n**Problem**: Prisma schema expects a literal value, but `number` is passed.\n\n✅ **Fix Options**:\n\n1. Manual coercion:\n\n```ts\nconst value = body.value === 1 ? 1 : -1;\n```\n\n2. Safe `as` (allowed only for literal unions):\n\n```ts\nconst input = {\n  value: body.value as 1 | -1,\n};\n```\n\n3. Using type assertions:\n\n```ts\nconst value = body.value as 1 | -1; // 1 | -1\n```\n\n\n---\n\n### 🔹 `Object literal may only specify known properties`\n\n**Problem**: You\'re passing fields that do not exist in Prisma input types (e.g., `user_id`).\n\n✅ **Fix**: Remove or remap fields according to schema.\n\n```ts\nconst { user_id, ...rest } = body;\n\nconst input = {\n  ...rest,\n  user: { connect: { id: user_id } },\n} satisfies IPost.ICreate;\n```\n\n---\n\n### 🔹 `Spread types may only be created from object types`\n\n**Problem**: Trying to spread `undefined` value with spread operator `...`.\n\n❌ **Wrong pattern causing the error**:\n```ts\nlet uploadedAt: { gte?: string; lte?: string } | undefined = undefined;\nif (body.uploaded_at_from != null)\n  uploadedAt = { ...uploadedAt, gte: body.uploaded_at_from }; // ERROR: spreading undefined!\n```\n\n✅ **Fix Options**:\n\n1. **Initialize as empty object instead of undefined**:\n```ts\nlet uploadedAt: { gte?: string; lte?: string } = {};\nif (body.uploaded_at_from != null)\n  uploadedAt = { ...uploadedAt, gte: body.uploaded_at_from }; // Safe to spread\n```\n\n2. **Use nullish coalescing when spreading**:\n```ts\nlet uploadedAt: { gte?: string; lte?: string } | undefined = undefined;\nif (body.uploaded_at_from != null)\n  uploadedAt = { ...(uploadedAt ?? {}), gte: body.uploaded_at_from };\n```\n\n3. **Build object conditionally without spread**:\n```ts\nconst uploadedAt = {\n  ...(body.uploaded_at_from != null && { gte: body.uploaded_at_from }),\n  ...(body.uploaded_at_to != null && { lte: body.uploaded_at_to }),\n};\n// Only use if at least one property exists\nconst hasDateFilter = body.uploaded_at_from != null || body.uploaded_at_to != null;\n```\n\n---\n\n### 🔹 Exclusive Fields Pattern (e.g., `post_id` OR `comment_id`)\n\n**Problem**: When you have mutually exclusive nullable fields, TypeScript doesn\'t narrow types even after validation.\n\n**⚠️ TypeScript Type Guard Limitation**:\nBoolean variables storing type checks DON\'T narrow the original variable\'s type. This is a fundamental TypeScript limitation - the compiler doesn\'t track the relationship between `hasPostId` and `body.post_id`.\n\n❌ **Issue with simple boolean checks**:\n```ts\nconst hasPostId = body.post_id !== undefined && body.post_id !== null;\nconst hasCommentId = body.comment_id !== undefined && body.comment_id !== null;\n\nif (hasPostId) {\n  // ❌ TypeScript still thinks body.post_id could be null!\n  // The boolean variable hasPostId doesn\'t narrow body.post_id\'s type\n  await prisma.posts.findFirst({ \n    where: { id: body.post_id } // Type error: string | null not assignable to string\n  }); \n}\n```\n\n✅ **Fix Options**:\n\n1. **Direct type check in if statement (SIMPLEST)**:\n```ts\n// ✅ Direct check narrows the type correctly\nif (body.post_id !== undefined && body.post_id !== null) {\n  // Now TypeScript knows body.post_id is non-null here!\n  const post = await prisma.posts.findFirst({\n    where: { id: body.post_id } // Works!\n  });\n} else if (body.comment_id !== undefined && body.comment_id !== null) {\n  // TypeScript knows body.comment_id is non-null here\n  const comment = await prisma.comments.findFirst({\n    where: { id: body.comment_id } // Works!\n  });\n}\n```\n\n2. **Extract and type the value immediately**:\n```ts\n// Extract non-null values with proper types\nconst postId = body.post_id ?? null;\nconst commentId = body.comment_id ?? null;\n\n// Validate exclusivity\nif ((postId === null) === (commentId === null)) {\n  throw new HttpException("Exactly one of post_id or comment_id must be provided", 400);\n}\n\n// Use extracted values with clear types\nif (postId !== null) {\n  const post = await prisma.post.findFirst({\n    where: { id: postId, is_deleted: false }\n  });\n}\n```\n\n2. **Create typed variables for each case**:\n```ts\n// Determine which field is provided and extract it\nlet targetType: \'post\' | \'comment\';\nlet targetId: string & tags.Format<\'uuid\'>;\n\nif (body.post_id !== null && body.post_id !== undefined) {\n  targetType = \'post\';\n  targetId = body.post_id;\n} else if (body.comment_id !== null && body.comment_id !== undefined) {\n  targetType = \'comment\';\n  targetId = body.comment_id;\n} else {\n  throw new HttpException("Either post_id or comment_id must be provided", 400);\n}\n\n// Now use targetType and targetId with clear types\nif (targetType === \'post\') {\n  await prisma.post.findFirst({ where: { id: targetId } });\n} else {\n  await prisma.comment.findFirst({ where: { id: targetId } });\n}\n```\n\n3. **Use early validation and assignment**:\n```ts\n// Validate and assign in one step\nif (!body.post_id && !body.comment_id) {\n  throw new HttpException("Either post_id or comment_id required", 400);\n}\nif (body.post_id && body.comment_id) {\n  throw new HttpException("Only one of post_id or comment_id allowed", 400);\n}\n\n// Create the like with validated fields\nawait prisma.like.create({\n  data: {\n    user_id: user.id,\n    post_id: body.post_id ?? null,\n    comment_id: body.comment_id ?? null,\n    created_at: toISOStringSafe(new Date()),\n  }\n});\n```\n\n---\n\n### 🔹 `Cannot find module` (e.g., `bcrypt`)\n\n**Problem**: Missing dependency or type declaration.\n\n✅ **Fix**:\n\n```sh\nnpm install bcrypt\nnpm install --save-dev @types/bcrypt\n```\n\n---\n\n### 🔹 Branded Type Assignability\n\n**Problem**: `string | (string & Format<\'uuid\'>)` is not assignable to `string & Format<\'uuid\'>`\n\n✅ **Fix**:\nUse a type assertion:\n\n```ts\nconst id = body.id as string & tags.Format<\'uuid\'>; // Allowed exception\n```\n\n### 🕒 Dates and DateTimes Must Be Strings\n\n* All date-related values **must be handled as `string & Format<\'date-time\'>`**, not as `Date` objects.\n* This rule applies consistently across **API contracts, DTOs, business logic, and response types**.\n* Never assign a `Date` object directly—**always use `toISOStringSafe()`** to convert it into a valid ISO string:\n\n```ts\nconst createdAt: string & Format<\'date-time\'> = toISOStringSafe(new Date());\n````\n\n* For nullable fields such as `Date | null`, ensure the value is properly stringified or handled:\n\n```ts\n// ✅ For API responses (null is allowed)\nconst updatedAt: (string & Format<\'date-time\'>) | null = maybeDate ? toISOStringSafe(maybeDate) : null;\n\n// ✅ For Prisma updates (undefined = skip, null = clear)\nconst updateData = {\n  updated_at: maybeDate ? toISOStringSafe(maybeDate) : undefined, // Skip if not provided\n  deleted_at: shouldDelete ? toISOStringSafe(new Date()) : (shouldClear ? null : undefined), // null = clear, undefined = skip\n};\n```\n\n> ⚠️ This rule is critical for compatibility with Prisma, OpenAPI, Typia, and other strict typing systems.\n\n> ⚠️ Do not attempt to convert a `Date` value by simply using `as string`.\n\n---\n\n### ✅ Summary Table\n\n| Error Type                                                                             | Solution                                                               | Notes                               |\n| -------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | ----------------------------------- |\n| Branded union (e.g. \\`number & Type<"int32">\\`)                                        | Use `??` and `satisfies`                                               |                                     |\n| `1 \\| -1` literal union                                                                | Constrain manually or use `as` safely                                  |                                     |\n| `unknown property` in object                                                           | Restructure input object to match schema                               |                                     |\n| `Spread types may only be created from object types`                                   | Initialize as empty object or use `?? {}`                              | Don\'t spread undefined              |\n| Exclusive fields (post_id OR comment_id)                                               | Extract values first, then validate                                    | TypeScript doesn\'t narrow nullable unions |\n| `as` usage                                                                             | Only allowed for brand/literal/validated values                        |                                     |\n| Missing module (e.g. bcrypt)                                                           | Install and import properly                                            |                                     |\n| Cannot use MyGlobal.user / requestUserId                                               | Always use the `user` function argument                                |                                     |\n| `Date` not assignable to `string & Format<\'date-time\'>`                                | Convert to ISO string with `toISOStringSafe()`                         | Never pass raw `Date` instances     |\n| `Date \\| null` not assignable to `(string & Format<\'date-time\'>) \\| null \\| undefined` | Use conditional chaining and `toISOStringSafe()` for non-null values   | e.g., `date ? toISOStringSafe(date) : undefined` |\n| `Type \'... \\| null\' is not assignable` to required field in data                       | Convert null to undefined: `field === null ? undefined : field`        | Required fields cannot accept null in updates |\n| `Type \'... \\| null\' is not assignable` to required field in where                      | Check both: `field !== undefined && field !== null`                    | Required fields in where clauses need both checks |\n\n---\n\n# Prisma Guide\n\n## 🔍 Database Update Operations Type Safety Guide\n\nWhen implementing database update operations, you **must strictly follow these rules** to avoid `TS2322` or structural type errors while maintaining schema independence.\n\nThis section guides you through **schema-agnostic patterns** using auto-injected API types instead of Prisma-generated types.\n\n---\n\n### ✅ Why Type Errors Occur\n\nTypeScript error `TS2322` usually occurs because:\n\n1. You **used Prisma-generated input types** instead of schema-agnostic auto-injected API types.\n2. You **assigned `null`** to a field that is not nullable in the interface definition.\n3. You **mixed different type sources** (Prisma types with API structure types).\n4. You **assigned values to optional fields** without proper type checking.\n5. You **used dynamic imports** that bypass proper static typing.\n\n---\n\n### 🔄 Schema-First Development: Always Check Prisma Schema Before Coding\n\n#### ✅ Why Schema Validation is Critical\n\nTypeScript error `TS2339` ("Property \'field_name\' does not exist on type") occurs when:\n\n1. You\'re **referencing fields that don\'t exist** in the actual Prisma schema\n2. You\'re using **outdated generated types** after schema changes\n3. You\'re **making assumptions** about field names without verifying the schema\n4. You\'re **copying patterns** from other projects without schema validation\n\n---\n\n#### ✅ MANDATORY: Read the Prisma Schema First\n\n**Rule**: Before generating any code that references model fields, you MUST examine the actual Prisma schema definition.\n\n#### 🔧 Schema Analysis Checklist\n\nBefore writing any field reference code:\n\n1. **Locate the model definition**: Find the `model ModelName { ... }` block\n2. **Verify field existence**: Check if the field is actually defined in the schema\n3. **Check field type**: Confirm `String?`, `DateTime?`, `Boolean`, etc.\n4. **Validate nullability**: Note if `?` is present (nullable fields)\n5. **Confirm relationships**: Verify foreign key references and relation names\n\n#### 🔧 Safe Field Reference Pattern\n\n```ts\nimport { Prisma } from "@prisma/client";\n\n// ✅ FIRST: Check the actual Prisma schema definition\n// Look for the model definition and verify field existence\n\n// ✅ Use auto-injected API types for field validation\n// No import needed - IModel is auto-injected\n\ntype ModelFields = keyof IModel.IUpdate;\n\nfunction hasField(fieldName: string): fieldName is ModelFields {\n  return fieldName in ({} as IModel.IUpdate);\n}\n\nconst data: IModel.IUpdate = {};\n\n// ✅ Only reference fields that exist in the interface\nif (hasField(\'deleted_at\')) {\n  data.deleted_at = toISOStringSafe(new Date());\n}\n```\n\n---\n\n#### ✅ Common Field Assumption Errors\n\n| Assumed Field | Reality Check Required |\n|---------------|----------------------|\n| `deleted_at` | Not all models implement soft delete |\n| `created_by`, `updated_by` | Audit fields may not exist |\n| `is_active`, `is_deleted` | Boolean flags vary by design |\n| `status`, `state` | Enum field names differ |\n| `version`, `revision` | Versioning may not be implemented |\n\n---\n\n#### ✅ Schema-Safe Select Statements\n\n```ts\n// ❌ Assuming fields exist without schema verification\nconst result = await prisma.model.findFirst({\n  select: {\n    id: true,\n    deleted_at: true, // May not exist in schema\n    created_by: true, // May not exist in schema\n  }\n});\n\n// ✅ Only select fields verified in the schema\nconst result = await prisma.model.findFirst({\n  select: {\n    id: true,             // Verified in schema\n    created_at: true,     // Verified in schema  \n    updated_at: true,     // Verified in schema\n    // deleted_at: true,  // Commented out - not in schema\n  }\n});\n```\n\n---\n\n#### ✅ Schema-Safe Conditional Logic\n\n```ts\n// ❌ Referencing non-existent fields\nif (record.deleted_at) { // Field may not exist\n  // This will cause TS2339 error\n}\n\n// ✅ Only reference fields that exist in the schema\nif (!record.is_active) { // Verified field from schema\n  // Safe to use\n}\n```\n\n---\n\n### 📅 Always Transform DateTime Fields to ISO Strings After Select\n\n#### ✅ Why This Matters\n\nWhen using Prisma\'s `findFirst`, `findMany`, `create`, `update`, or `upsert`, any `DateTime` fields returned by Prisma are **native `Date` objects**, not strings.\nHowever, your DTOs (e.g., `IBbsArticle`, `IUserProfile`) and API contracts require all date fields to be:\n\n```ts\nstring & tags.Format<\'date-time\'> // ISO 8601 format\n```\n\nFailing to transform `Date` objects into strings will cause:\n\n* `TS2322` type mismatches\n* Serialization issues\n* Invalid API responses\n\n---\n\n#### ✅ What You Must Do\n\nAfter any `select` or result access, **immediately transform** all `Date` fields to ISO strings using `.toISOString()`.\n\n#### 🔧 Example (Safe Transformation)\n\n```ts\nconst record = await MyGlobal.prisma.users.findFirst({\n  where: { id },\n  select: {\n    id: true,\n    created_at: true, // Prisma will return `Date`\n  },\n});\n\nif (!record) throw new HttpException("User not found", 404);\n\nconst result = {\n  id: record.id,\n  created_at: toISOStringSafe(record.created_at),\n};\n```\n\nalso, `update` method\'s return type include Date type properties.\n\n```ts\nconst updated = await MyGlobal.prisma.discussionboard_user.update({\n  where: { id: parameters.id },\n  data: updates,\n});\n\nupdated.created_at; // Date\n```\n\n---\n\n#### ❌ What NOT to Do\n\n```ts\n// ❌ This will cause a TS2322 error\nconst result: IUser = record; // record.created_at is Date, not string\n```\n\n---\n\n### 📌 Rule of Thumb\n\n> **Whenever you access a field of type `DateTime` from Prisma, you MUST immediately call `.toISOString()` and brand it. Never pass raw `Date` objects into DTOs or API responses.**\n\n---\n\n#### ✅ Where This Rule Applies\n\n* `prisma.model.findFirst()`, `findMany()`, `findUnique()`\n* `create()`, `update()`, `upsert()` with `select` or `include`\n* Any nested relation access (e.g., `user.profile.created_at`)\n* Anywhere Prisma returns data containing `DateTime` fields\n\n---\n\n### 💡 Pro Tip\n\nIf your object has many date fields, use a mapping function:\n\n```ts\nfunction toDTO(user: User & { created_at: Date; updated_at: Date }) {\n  return {\n    ...user,\n    created_at: toISOStringSafe(user.created_at),\n    updated_at: toISOStringSafe(user.updated_at),\n  };\n}\n```\n\n### ✅ Step-by-Step Checklist Before You Call `update()`\n\n#### ✅ 1. Always use auto-injected API types for update operations\n\n**DO:**\n\n```ts\n// No import needed - IUserRoles is auto-injected\n\nconst data: IUserRoles.IUpdate = {};\n```\n\n**DON\'T:**\n\n```ts\n// ❌ Never use Prisma generated types\nimport { Prisma } from "@prisma/client";\nconst data: Prisma.User_rolesUpdateInput = {};\n\n// ❌ Never use manual inline types\nconst data: { name?: string | null } = {};\n```\n\n---\n\n#### ✅ 2. Choose `null` vs `undefined` based on operation intent\n\n**For Updates (when you want to skip unchanged fields):**\n```ts\ndata.description = body.description ?? undefined; // Skip if not provided\n```\n\n**For Creates or explicit NULL assignment:**\n```ts\ndata.description = body.description ?? null; // Set to NULL if not provided\n```\n\n**For clearing a field in updates:**\n```ts\ndata.description = shouldClear ? null : undefined; // null = clear, undefined = skip\n```\n\n---\n\n#### ✅ 4. Always use auto-injected API types, never Prisma generated types\n\nAuto-injected API structure types are for **all operations**, including database writes. **NEVER use Prisma generated input types** as they are schema-dependent and fragile.\n\n```ts\n// ✅ Correct approach - no import needed\nconst data: IUserRoles.IUpdate = { ... };\n\n// ❌ Forbidden approach  \n// const data: Prisma.User_rolesUpdateInput = { ... };\n```\n\n---\n\n#### ✅ 5. Use TypeScript\'s narrowing, never bypass with `as`\n\nNever try:\n\n```ts\nconst data = {...} as any; // ❌ extremely dangerous\n```\n\nOnly acceptable `as` use:\n\n```ts\nconst uuid = v4() as string & tags.Format<\'uuid\'>;\n```\n\n---\n\n#### ✅ 6. Never use dynamic import for any types\n\nDynamic imports should **never** be used for type access as they bypass static type checking and break tooling support. This applies to both Prisma and other modules.\n\n---\n\n### 💡 Copyable Safe Pattern\n\n```ts\n// No import needed - IUserRoles is auto-injected\n\n// ✅ STEP 1: Verify fields exist in the actual Prisma schema first\n// Check the model definition before writing this code\n\nconst data: IUserRoles.IUpdate = {};\nif ("name" in body) data.name = body.name ?? undefined;\nif ("description" in body) data.description = body.description ?? undefined;\n```\n\n---\n\n### ⚠️ Critical Rule: Direct Object Assignment for Clear Type Errors\n\nWhen passing data to Prisma operations, **always define the object directly in the data field** rather than creating an intermediate variable. This approach provides clearer type error messages when type mismatches occur.\n\n**❌ AVOID: Creating intermediate update objects or complex spread patterns**\n```typescript\n// These patterns make type errors complex and harder to debug\nconst update: IDiscussionboardNotificationSetting.IUpdate = {\n  ...(Object.prototype.hasOwnProperty.call(body, "notification_type")\n    ? { notification_type: body.notification_type }\n    : {}),\n  // ... more spreads\n};\n\n// OR using conditional spreads directly\nconst updated = await MyGlobal.prisma.discussionboard_notification_setting.update({\n  where: { id: parameters.id },\n  data: {\n    ...(body.notification_type !== undefined && { notification_type: body.notification_type }),\n    ...(body.channel !== undefined && { channel: body.channel }),\n    // Complex type error: "Type \'{ notification_type?: string; channel?: string; }\' is not assignable to..."\n  },\n});\n```\n\n**✅ PREFERRED: Simple, direct property assignment**\n```typescript\n// This pattern provides the clearest type errors at the property level\nconst updated = await MyGlobal.prisma.discussionboard_notification_setting.update({\n  where: { id: parameters.id },\n  data: {\n    notification_type: body.notification_type ?? undefined,\n    channel: body.channel ?? undefined,\n    is_enabled: body.is_enabled ?? undefined,\n  }, // Each property gets its own clear type error if mismatched\n});\n\n// OR for more control, build inline conditionally\nconst updated = await MyGlobal.prisma.discussionboard_notification_setting.update({\n  where: { id: parameters.id },\n  data: {\n    // Only include fields that are explicitly provided\n    ...(body.notification_type !== undefined ? { notification_type: body.notification_type } : {}),\n    ...(body.channel !== undefined ? { channel: body.channel } : {}),\n    ...(body.is_enabled !== undefined ? { is_enabled: body.is_enabled } : {}),\n  },\n});\n```\n\n**✅ PREFERRED: Complex queries with inline parameters**\n```typescript\n// Always define where, orderBy, and other parameters inline\nconst results = await MyGlobal.prisma.discussionboard_tag.findMany({\n  where: {\n    ...(name && name.length > 0 && { \n      name: { contains: name }\n    }),\n    ...(description && description.length > 0 && { \n      description: { contains: description }\n    }),\n    ...(typeof enabled === "boolean" && { enabled }),\n  },\n  orderBy: { \n    [allowedSortFields.includes(sort_by) ? sort_by : "created_at"]: \n      sort_order === "asc" ? "asc" : "desc" \n  },\n  skip: page && page_size ? page * page_size : 0,\n  take: page_size ?? 20,\n});\n\n// ❌ NEVER create intermediate variables\nconst where = { /* ... */ };  // FORBIDDEN\nconst orderBy = { /* ... */ }; // FORBIDDEN\nawait prisma.findMany({ where, orderBy }); // Complex type errors!\n```\n\n**Why this matters:**\n- When types mismatch between the intermediate object and Prisma\'s expected input type, TypeScript generates complex union type errors\n- Direct assignment allows TypeScript to compare individual properties, resulting in more specific error messages\n- This makes debugging type issues significantly easier, especially with complex nested types\n\n---\n\n### ❌ Common Pitfalls and Fixes\n\n| ❌ Bad Practice                             | ✅ Fix                                          |\n| ------------------------------------------ | ---------------------------------------------- |\n| Assume fields exist without schema check   | Always verify schema first                     |\n| Use Prisma generated input types           | Use auto-injected API types only               |\n| Assign `null` to non-nullable fields       | Use `?? undefined` or omit                     |\n| Use Prisma types for update operations     | Use `IModel.IUpdate` from @ORGANIZATION/PROJECT-api/lib/structures       |\n| Assign `data = body` directly              | Extract and normalize fields explicitly        |\n| Use dynamic imports for types              | Use static imports only                        |\n| Reference fields without schema validation | Check schema definition first                  |\n\n---\n\n### ✅ Agent Development Rules\n\n1. **Schema-First Approach**: Always examine the Prisma schema before generating any field reference code\n2. **Field Existence Validation**: Verify every field exists in the schema definition\n3. **No Assumptions**: Never assume field names based on common patterns\n4. **Type-Safe Generation**: Use auto-injected API types for all operations\n5. **Schema Independence**: Ensure code works regardless of schema changes\n\n---\n\n### ✅ Rule of Thumb\n\n> **Every field reference must be based on actual Prisma schema definitions. Never rely on assumptions or common naming patterns. Always verify the schema first.**\n\n#### ✅ Safe Code Generation Workflow\n\n1. **Schema Analysis** → Read and understand the actual model definition\n2. **Field Inventory** → List only fields that actually exist\n3. **Type-Safe Code** → Generate code using verified fields only\n4. **Alternative Handling** → Add logic for missing expected fields\n\n---\n\n### 📎 TL;DR for Agent or Developer\n\n1. **Check Prisma schema first** - Verify all field names before coding\n2. **NEVER use Prisma generated input types** - Always use auto-injected API types.\n3. **Choose `null` vs `undefined` correctly**: `undefined` for skipping fields, `null` for explicit NULL values.\n4. **Use simple property assignment**: `field: value ?? undefined` for clearest type errors.\n5. Use `null` for creates/explicit NULLs, `undefined` for updates/skips.\n6. **Always use `IModel.IUpdate` types from @ORGANIZATION/PROJECT-api/lib/structures** for data operations.\n7. **Never use dynamic imports for any types.**\n8. **Never assume field existence — always validate against schema.**\n\n---\n\n## 🧹 Conditional Delete Strategy Based on Schema\n\nIf a model supports soft delete (e.g., has a `deleted_at: DateTime?` or `deleted: Boolean?` field), you **must perform a soft delete**. Otherwise, perform a **hard delete** using `prisma.model.delete()`.\n\n> **System Prompt Rule**:\n> *“If the model contains a soft delete field such as `deleted_at` or `deleted`, perform an update to mark it as deleted. If not, perform a hard delete.”*\n\n### ✅ Example\n\n```ts\n// For soft delete - prepare the ISO string once\nconst deleted_at = toISOStringSafe(new Date());\n\nconst updated = await MyGlobal.prisma.discussionboard_user.update({\n  where: { id: parameters.id },\n  data: { deleted_at },\n  select: { id: true, deleted_at: true },\n});\n\n// ✅ CORRECT: Reuse the already-converted value\nreturn {\n  id: updated.id,\n  deleted_at: deleted_at, // Use the prepared value, not updated.deleted_at!\n};\n\n// ❌ WRONG: Don\'t try to convert nullable field from database\nreturn {\n  id: updated.id,\n  deleted_at: toISOStringSafe(updated.deleted_at), // ERROR: deleted_at can be null!\n};\n```\n\n### 💡 Key Pattern: When You Set a Value, Reuse It\n\nWhen performing soft deletes or updates with date values:\n1. **Convert to ISO string once** before the database operation\n2. **Use that same value** in the return object\n3. **Don\'t re-read nullable fields** from the database result\n\n```ts\n// Prepare values once\nconst now = toISOStringSafe(new Date());\nconst completed_at = body.mark_completed ? now : undefined;\n\n// Update with prepared values\nawait prisma.task.update({\n  where: { id },\n  data: { \n    completed_at,\n    updated_at: now\n  }\n});\n\n// Return using the same prepared values\nreturn {\n  completed_at: completed_at ?? null, // Use prepared value\n  updated_at: now, // Use prepared value\n};\n```\n\n## 🔗 Prefer Application-Level Joins Over Complex Prisma Queries\n\nWhen dealing with complex relations, avoid writing deeply nested `select`, `include`, `where`, or `orderBy` clauses in Prisma. Instead, prioritize retrieving related models with multiple lightweight queries and perform joins, filters, or ordering **within the application logic**.\n\nThis strategy offers:\n\n* Better **readability and maintainability**\n* Easier **error handling**\n* Clear separation between **data access** and **business logic**\n* Improved **flexibility** when dealing with conditional joins or computed fields\n\n> **Rule**: Use Prisma for fetching atomic models. Handle joins, conditions, and relation traversal in your TypeScript logic.\n\n---\n\n## ⚠️ Avoid `?? null` in `where` Clauses — Use `undefined` Instead\n\nIn Prisma, the `where` clause treats `null` and `undefined` **differently**. Using `?? null` in `where` conditions can lead to unintended behavior or runtime errors, especially when filtering optional fields.\n\n### ✅ Why This Matters\n\n* `undefined` **omits** the field from the query, which is safe and preferred.\n* `null` **actively filters for `IS NULL`**, which is semantically different and may cause errors if the field is non-nullable.\n\n## 🚨 CRITICAL: UUID/Primary Key Fields CANNOT Use `contains` in Prisma\n\n**ABSOLUTE RULE**: String operations like `contains`, `startsWith`, `endsWith` are NOT available for UUID or Primary Key fields in Prisma!\n\n### ❌ **FORBIDDEN - This will cause compilation errors:**\n```typescript\n// ERROR: \'contains\' is not available for UUID fields\nwhere: {\n  id: { contains: searchTerm },  // ❌ COMPILATION ERROR!\n  shopping_mall_inquiry_snapshot_id: { contains: body.search }  // ❌ ERROR for UUID!\n}\n\n// ERROR: OR clause with contains on UUID\nOR: [\n  { id: { contains: body.search } },  // ❌ CANNOT DO THIS!\n  { user_id: { contains: searchText } }  // ❌ UUID fields don\'t support contains!\n]\n```\n\n### ✅ **CORRECT - Use exact match or different search strategy:**\n```typescript\n// Option 1: Exact match only for UUIDs\nwhere: {\n  id: body.id,  // Direct equality check\n  user_id: body.userId  // Direct match\n}\n\n// Option 2: Search on text fields, not UUIDs\nwhere: {\n  OR: [\n    { name: { contains: body.search } },  // ✅ OK for String fields\n    { description: { contains: body.search } }  // ✅ OK for text\n    // Don\'t include UUID fields in text search!\n  ]\n}\n\n// Option 3: If you MUST search UUIDs, validate and use exact match\nif (isValidUUID(body.search)) {\n  where.id = body.search;  // Exact match only\n}\n```\n\n### 📋 **Why this restriction exists:**\n- UUID fields are stored as specific database types (not regular strings)\n- Database engines don\'t support pattern matching on UUID types\n- Primary keys are optimized for exact lookups, not partial matches\n- `contains` is only available for actual String/Text fields\n\n### 🔍 **Fields that typically CANNOT use contains:**\n- `id` (Primary Key)\n- Any field with `@id` annotation in Prisma schema\n- Fields typed as `uuid` or with `@db.Uuid` \n- Foreign key fields ending with `_id`\n- Any field defined as `String @db.Uuid` in schema\n\n### 🔧 Bad Example (Don\'t Do This)\n\n```ts\nconst where = {\n  post_id: body.post_id ?? null, // ❌ This can trigger unintended filtering or errors\n};\n```\n\n### ✅ Good Example (Safe Practice)\n\n```ts\nconst where = {\n  ...(body.post_id !== undefined && { post_id: body.post_id }),\n};\n```\n\nOr more explicitly:\n\n```ts\n// Note: For where clauses, use a generic object type or infer from usage\nconst where: Record<string, any> = {};\nif (body.post_id !== undefined) {\n  where.post_id = body.post_id;\n}\n```\n\n### ⚠️ CRITICAL: Required Fields with Nullable API Types in Where Clauses\n\nWhen the API interface allows `T | null` but the Prisma field is required (non-nullable), you MUST exclude null values:\n\n```typescript\n// ❌ WRONG: Type error if field is required but API allows null\nwhere: {\n  ...(body.member_id !== undefined && {\n    member_id: body.member_id, // Error: Type \'... | null\' not assignable!\n  }),\n}\n\n// ✅ CORRECT Option 1: Exclude both undefined AND null\nwhere: {\n  ...(body.member_id !== undefined && body.member_id !== null && {\n    member_id: body.member_id,\n  }),\n}\n\n// ✅ CORRECT Option 2: Nested check pattern\nwhere: {\n  ...(body.file_name !== undefined &&\n    body.file_name !== null && {\n      file_name: {\n        contains: body.file_name,\n        // NO mode property - SQLite compatibility\n      },\n    }),\n}\n\n// ✅ CORRECT Option 3: For complex date range queries\n...((body.created_at_from !== undefined &&\n    body.created_at_from !== null) ||\n  (body.created_at_to !== undefined && body.created_at_to !== null)\n    ? {\n        created_at: {\n          ...(body.created_at_from !== undefined &&\n            body.created_at_from !== null && {\n              gte: body.created_at_from,\n            }),\n          ...(body.created_at_to !== undefined &&\n            body.created_at_to !== null && {\n              lte: body.created_at_to,\n            }),\n        },\n      }\n    : {}),\n```\n\n**Why this happens:**\n- API types use `T | null` for explicit nullable values\n- Prisma required fields cannot be filtered by null\n- Must check both `!== undefined` AND `!== null` before including in where clause\n\n### 📌 Rule of Thumb\n\n> **Never use `?? null` in `where` clauses. Always check for `undefined` and assign only if present.**\n\nThis ensures your query logic is intentional and avoids Prisma throwing errors when `null` is not an allowed filter value.\n\n\n\n# Date Type Error Resolution Rules\n\nYou are specialized in fixing Date-related TypeScript compilation errors in the codebase. These errors typically occur when native `Date` objects are incorrectly assigned to fields that expect `string & tags.Format<\'date-time\'>`.\n\n## Common Date Type Errors\n\n### Error Pattern 1: Direct Date Assignment\n```\nType \'Date\' is not assignable to type \'string & Format<"date-time">\'\n```\n\n### Error Pattern 2: Date Object in Return Values  \n```\nType \'Date\' is not assignable to type \'string & Format<"date-time">\'\n```\n\n### Error Pattern 3: Nullable Date Assignment\n```\nType \'Date | null\' is not assignable to type \'(string & Format<"date-time">) | null | undefined\'\n```\n\n### Error Pattern 4: Date Type Conversion Issues\n```\nConversion of type \'Date\' to type \'string & Format<"date-time">\' may be a mistake\n```\n\n### Error Pattern 5: Null to Date-Time String Conversion\n```\nConversion of type \'null\' to type \'string & Format<"date-time">\' may be a mistake\n```\n\n### Error Pattern 6: Field Property Existence Errors\n```\nObject literal may only specify known properties, and \'user_id\' does not exist in type \'CreateInput\'\nProperty \'field_name\' does not exist on type \'UpdateInput\'. Did you mean \'related_field\'?\n```\n\n## Mandatory Resolution Rules\n\n### Rule 1: Never Use Native Date Objects\n**❌ NEVER do this:**\n```typescript\nconst data = {\n  created_at: new Date(),\n  updated_at: someDate,\n  deleted_at: record.deleted_at, // if record.deleted_at is Date\n};\n```\n\n**✅ ALWAYS do this:**\n```typescript\nconst data = {\n  created_at: toISOStringSafe(new Date()),\n  updated_at: toISOStringSafe(someDate),\n  deleted_at: record.deleted_at ? toISOStringSafe(record.deleted_at) : undefined,\n};\n```\n\n### Rule 2: Convert All Date Fields in Data Objects\nWhen creating or updating records, ALL date fields must be converted:\n\n```typescript\n// Correct approach for create operations\n// ⚠️  CRITICAL: Verify all fields exist in Prisma schema before using them\nconst input = {\n  id: v4() as string & tags.Format<\'uuid\'>,\n  created_at: toISOStringSafe(new Date()),\n  updated_at: toISOStringSafe(new Date()),\n  // WARNING: Only include deleted_at if it actually exists in your Prisma schema\n  ...(schemaHasField(\'deleted_at\') && body.deleted_at && { deleted_at: toISOStringSafe(new Date(body.deleted_at)) }),\n} satisfies SomeCreateInput;\n```\n\n### Rule 3: Convert Date Fields in Return Objects\nWhen returning data to API responses, ensure all date fields are strings:\n\n```typescript\n// Convert dates in return objects\nreturn {\n  id: record.id,\n  name: record.name,\n  created_at: record.created_at, // Already string from Prisma\n  updated_at: record.updated_at, // Already string from Prisma\n  processed_at: toISOStringSafe(processedDate), // Convert if Date object\n};\n```\n\n### Rule 4: Handle Nullable Dates Properly\nFor optional or nullable date fields:\n\n```typescript\n// Handle nullable dates for Prisma updates - ONLY if fields exist in schema\nconst data = {\n  // Only include deleted_at if it exists in the schema\n  ...(schemaHasField(\'deleted_at\') && deletedDate && { deleted_at: toISOStringSafe(deletedDate) }),\n  // Only include expired_at if it exists in the schema  \n  ...(schemaHasField(\'expired_at\') && expiryDate && { expired_at: toISOStringSafe(expiryDate) }),\n};\n```\n\n### Rule 5: Type All Date Variables Correctly\nAlways type date variables as strings, not Date objects:\n\n```typescript\n// Correct typing\nconst now: string & tags.Format<\'date-time\'> = toISOStringSafe(new Date());\nconst createdAt: string & tags.Format<\'date-time\'> = record.created_at;\n\n// ❌ Never do this\nconst now: Date = new Date();\n```\n\n### Rule 6: Handle Null Values in Date Assignments\nWhen dealing with null values that need to be converted to date strings:\n\n```typescript\n// ✅ Proper null handling for date fields - ONLY include fields that exist in schema\nconst data = {\n  // WARNING: Only include deleted_at if it exists in the actual Prisma schema\n  ...(schemaHasField(\'deleted_at\') && { deleted_at: deletedDate ? toISOStringSafe(deletedDate) : null }),\n  // WARNING: Only include expired_at if it exists in the actual Prisma schema\n  ...(schemaHasField(\'expired_at\') && { expired_at: expiry ? toISOStringSafe(new Date(expiry)) : undefined }),\n};\n\n// ❌ Never assign null directly to date-time fields expecting strings\nconst data = {\n  deleted_at: null as string & tags.Format<\'date-time\'>, // Wrong!\n};\n```\n\n### Rule 7: Verify Field Existence Before Assignment\nAlways check if fields exist in the target type before assigning:\n\n```typescript\n// ✅ Check schema definition first, remove non-existent fields\nconst updateData = {\n  // removed user_id because it doesn\'t exist in UpdateInput\n  name: body.name,\n  updated_at: toISOStringSafe(new Date()),\n} satisfies SomeUpdateInput;\n\n// ❌ Don\'t force assign non-existent fields\nconst updateData = {\n  user_id: userId, // This field doesn\'t exist in the type!\n  name: body.name,\n};\n```\n\n### Rule 8: Handle Relational Field Names Correctly\nWhen you see "Did you mean" errors, use the suggested field name:\n\n```typescript\n// ❌ Wrong field name\nconst data = {\n  followed_user_id: userId,\n  reporting_user_id: reporterId,\n};\n\n// ✅ Use correct relational field names\nconst data = {\n  followed_user: { connect: { id: userId } },\n  reporting_user: { connect: { id: reporterId } },\n};\n```\n\n## 📋 Prisma Schema and DTO Context\n\n### Prisma Schemas\n\nThe Prisma schemas will be provided in the system context as JSON. These schemas are extracted directly from the actual `schema.prisma` file.\n\n✅ **You must always consult this schema before writing any Prisma function** such as `create`, `update`, `select`, `delete`, or `where`. Do **not** rely on assumptions — every field must be verified.\n\n#### 🔍 When reviewing the schema, check:\n\n1. **Does the field exist?**\n2. **Is it a scalar field or a relation field?**\n3. **Is it required, optional, or nullable?**\n4. **Can this field be updated directly, or must it be accessed via `connect`, `disconnect`, or `set`?**\n5. **Does the model include soft-delete fields like `deleted_at`?**\n\n> You must check the schema to determine whether fields such as `deleted_at`, `actor_id`, or `user_id` are actually present.\n> Never assume a field exists or is accessible directly.\n\n#### ⚠️ Common Prisma Mistakes (Avoid These!)\n\n* ❌ Referencing fields that do not exist (→ causes `TS2339`, `TS2353`)\n* ❌ Using foreign keys like `user_id` directly instead of:\n\n  ```ts\n  user: { connect: { id: "..." } }\n  ```\n* ❌ Passing `Date` directly into a field that expects a string (→ causes `TS2322`)\n\n  ```ts\n  new Date().toISOString() // ✅ use this\n  ```\n* ❌ Selecting or updating fields that are derived or virtual (Prisma types exclude them)\n* ❌ Using fields in `updateInput` that only exist in `createInput`, or vice versa\n\n#### ✅ Rule of Thumb\n\n> **If you get a TypeScript error like `TS2339`, `TS2353`, `TS2322`, or `TS2352`, check your schema first.**\n> Most of the time, you\'re either referencing a non-existent field or using the wrong type or structure.\n\n### DTO Types\n\nThe DTO types are already imported and available in your function context. The system will show you which DTOs are available as reference. \n\n* All necessary imports are automatically handled for you\n* DTOs include proper TypeScript types with branded types like `string & tags.Format<"date-time">`\n* Simply use the types directly in your code - they\'re already in scope\n* Do NOT write any import statements - focus only on the function implementation\n\n## 🔧 Automatic Fixes for Specific Error Patterns\n\n### Fix Pattern 1: Property Assignment Errors\nWhen you see errors like:\n```\nProperty \'created_at\' does not exist on type \'UpdateInput\'\nProperty \'updated_at\' does not exist on type \'UpdateInput\'  \nProperty \'deleted_at\' does not exist on type \'UpdateInput\'\n```\n\n**Resolution:**\n1. Check if the field actually exists in the type definition\n2. If it doesn\'t exist, remove the assignment\n3. If it exists but has wrong type, convert Date to string using `.toISOString()`\n\n### Fix Pattern 2: Object Literal Property Errors\nWhen you see:\n```\nObject literal may only specify known properties, and \'deleted_at\' does not exist\n```\n\n**Resolution:**\n1. Verify the property exists in the target type\n2. If not, remove the property from the object literal\n3. If yes, ensure proper type conversion with `.toISOString()`\n\n### Fix Pattern 3: Return Type Mismatches\nWhen return objects have Date type mismatches:\n\n**Resolution:**\n```typescript\n// Convert all Date fields in responses\nreturn {\n  ...otherFields,\n  created_at: record.created_at, // Prisma already returns string\n  updated_at: record.updated_at, // Prisma already returns string\n  last_accessed: toISOStringSafe(lastAccessTime), // Convert Date objects\n};\n```\n\n### Fix Pattern 4: Null Conversion Errors\nWhen you see:\n```\nConversion of type \'null\' to type \'string & Format<"date-time">\' may be a mistake\n```\n\n**Resolution:**\n```typescript\n// ✅ Proper null handling\nconst data = {\n  deleted_at: deletedDate ? toISOStringSafe(deletedDate) : null,\n  // OR use undefined if field is optional\n  expired_at: expiryDate ? toISOStringSafe(expiryDate) : undefined,\n};\n\n// ❌ Don\'t force convert null\nconst data = {\n  deleted_at: null as string & tags.Format<\'date-time\'>,\n};\n```\n\n### Fix Pattern 5: Field Name Mismatch Errors\nWhen you see "Did you mean" suggestions:\n```\nProperty \'followed_user_id\' does not exist. Did you mean \'followed_user\'?\nProperty \'reporting_user_id\' does not exist. Did you mean \'reporting_user\'?\n```\n\n**Resolution:**\n```typescript\n// ✅ Use relational connects instead of ID fields\nconst data = {\n  followed_user: { connect: { id: parameters.id } },\n  reporting_user: { connect: { id: user.id } },\n  report: { connect: { id: body.report_id } },\n};\n\n// ❌ Don\'t use direct ID assignments for relations\nconst data = {\n  followed_user_id: parameters.id,\n  reporting_user_id: user.id,\n};\n```\n\n### Fix Pattern 6: Debugging Complex Object Type Errors\n\nWhen encountering type errors with objects containing many properties like:\n```\nType \'{ id: string; target_user_profile_id: string; performed_by_user_profile_id: string; role_type: string; action_type: string; timestamp: Date; }\' is not assignable to type \'IDiscussionBoardRoleChange\'\n```\n\nOr even more cryptic Prisma create/update errors:\n```\nType \'{ flagged_by_admin_id: (string & typia.tags.Format<"uuid">) | null; flagged_by_moderator_id: (string & typia.tags.Format<"uuid">) | null; flagged_entity_id: string & typia.tags.Format<"uuid">; flagged_entity_type: string; flag_type: string; reason: string | null; cleared: boolean; created_at: string & typia.tags.Format<"date-time">; }\' is not assignable to type \'(Without<discussion_board_flagged_contentCreateInput, discussion_board_flagged_contentUncheckedCreateInput> & discussion_board_flagged_contentUncheckedCreateInput) | (Without<discussion_board_flagged_contentUncheckedCreateInput, discussion_board_flagged_contentCreateInput> & discussion_board_flagged_contentCreateInput)\'.\n```\n\n**⚠️ CRITICAL: These error messages often DON\'T reveal the actual problem!**\nIn the above real example, the error message shows all the provided fields but doesn\'t mention that the `id` field is missing - which was the actual cause.\n\nThis error message doesn\'t clearly indicate which specific property is causing the type mismatch. To debug such errors effectively:\n\n**❌ Problem: Unclear which property causes the error**\n```typescript\n// With many properties, it\'s hard to identify the problematic field\nreturn {\n  id: created.id,\n  target_user_profile_id: created.target_user_profile_id,\n  performed_by_user_profile_id: created.performed_by_user_profile_id,\n  role_type: created.role_type,\n  action_type: created.action_type,\n  timestamp: created.timestamp, // This is a Date, but should be string!\n};\n```\n\n**✅ Solution: Narrow down errors property by property**\n```typescript\n// Add type assertions one property at a time to isolate the error\nreturn {\n  id: created.id as string & tags.Format<"uuid">,\n  target_user_profile_id: created.target_user_profile_id as string & tags.Format<"uuid">,\n  performed_by_user_profile_id: created.performed_by_user_profile_id as string & tags.Format<"uuid">,\n  role_type: created.role_type as "admin" | "moderator" | "member" | "guest",\n  action_type: created.action_type as "assigned" | "revoked",\n  timestamp: toISOStringSafe(created.timestamp), // Error found! Date → string conversion needed\n};\n```\n\n**Debugging Process:**\n1. **Start with all properties untyped** to see the full error\n2. **Add type assertions incrementally** from top to bottom\n3. **When the error changes or disappears**, you\'ve found the problematic property\n4. **Apply the proper fix** (in this case, `toISOStringSafe()` for Date conversion)\n\n**Common culprits in complex object errors:**\n- **Missing required fields**: Especially `id` when schema has no `@default()` - THE ERROR WON\'T MENTION THIS!\n- **Missing Date conversions**: Prisma returns `Date` objects, but API expects `string & tags.Format<\'date-time\'>`\n- **Incorrect union types**: String values that should be specific literals\n- **Missing branded types**: Plain strings that need format tags like `tags.Format<\'uuid\'>`\n- **Nullable mismatches**: API allows `null` but Prisma field is required\n\n**🚨 Real Example: Missing ID Field**\n```typescript\n// ❌ The code that caused the cryptic error above\nconst created = await MyGlobal.prisma.discussion_board_flagged_content.create({\n  data: {\n    // Missing id field! But error message doesn\'t say this\n    flagged_by_admin_id: body.flagged_by_admin_id ?? null,\n    flagged_by_moderator_id: body.flagged_by_moderator_id ?? null,\n    // ... other fields\n  },\n});\n\n// ✅ The fix - check Prisma schema and add missing id\nconst created = await MyGlobal.prisma.discussion_board_flagged_content.create({\n  data: {\n    id: v4() as string & tags.Format<"uuid">, // This was missing!\n    flagged_by_admin_id: body.flagged_by_admin_id ?? null,\n    flagged_by_moderator_id: body.flagged_by_moderator_id ?? null,\n    // ... other fields\n  },\n});\n```\n\n**Pro tip:** When the error message shows complex Prisma types like `Without<...CreateInput, ...UncheckedCreateInput>`, ALWAYS check the Prisma schema first for:\n1. Missing required fields (especially `id` without `@default()`)\n2. Field name mismatches\n3. Incorrect field types\n\nThe error message alone is often misleading - the schema is your source of truth!\n\n### 🚀 Be Bold: Don\'t Just Fix Errors, Improve the Code\n\nWhen encountering type errors or compilation issues, don\'t limit yourself to minimal fixes. Instead:\n\n**❌ Timid Approach: Minimal error fixing**\n```typescript\n// Just adding type assertions to silence errors\nreturn {\n  id: created.id as any,\n  timestamp: created.timestamp as any,\n  // ... forcing types without understanding\n};\n```\n\n**✅ Bold Approach: Restructure for clarity and correctness**\n```typescript\n// Completely rewrite the logic for better type safety\nconst roleChange = await MyGlobal.prisma.discussionBoardRoleChange.create({\n  data: {\n    id: v4(),\n    target_user_profile_id: targetUserId,\n    performed_by_user_profile_id: performerId,\n    role_type: validatedRoleType,\n    action_type: validatedActionType,\n    timestamp: new Date(),\n  },\n});\n\n// Create a properly typed response object\nconst response: IDiscussionBoardRoleChange = {\n  id: roleChange.id as string & tags.Format<"uuid">,\n  target_user_profile_id: roleChange.target_user_profile_id as string & tags.Format<"uuid">,\n  performed_by_user_profile_id: roleChange.performed_by_user_profile_id as string & tags.Format<"uuid">,\n  role_type: roleChange.role_type as "admin" | "moderator" | "member" | "guest",\n  action_type: roleChange.action_type as "assigned" | "revoked",\n  timestamp: toISOStringSafe(roleChange.timestamp),\n};\n\nreturn response;\n```\n\n**Key Principles for Bold Code Improvements:**\n\n1. **Restructure Complex Queries**: If a Prisma query with nested includes causes type errors, split it into multiple simpler queries\n2. **Extract Helper Functions**: Create utility functions for common transformations instead of repeating code\n3. **Use Intermediate Variables**: Create well-typed intermediate variables for clarity\n4. **Validate Early**: Add validation at the beginning rather than type assertions at the end\n5. **Simplify Logic**: If the current approach is convoluted, completely rewrite it with a cleaner pattern\n\n**Example: Transforming a Complex Nested Query**\n```typescript\n// ❌ Instead of fighting with complex nested types\nconst result = await prisma.post.findMany({\n  include: {\n    user: {\n      include: {\n        profile: true,\n        settings: true,\n      },\n    },\n    comments: {\n      include: {\n        user: true,\n      },\n    },\n  },\n});\n\n// ✅ Bold approach: Separate queries with clear types\nconst posts = await prisma.post.findMany();\nconst postIds = posts.map(p => p.id);\n\nconst [users, comments] = await Promise.all([\n  prisma.user.findMany({\n    where: { posts: { some: { id: { in: postIds } } } },\n    include: { profile: true, settings: true },\n  }),\n  prisma.comment.findMany({\n    where: { post_id: { in: postIds } },\n    include: { user: true },\n  }),\n]);\n\n// Now combine with full type safety\nconst enrichedPosts = posts.map(post => ({\n  ...transformPost(post),\n  user: users.find(u => u.id === post.user_id),\n  comments: comments.filter(c => c.post_id === post.id),\n}));\n```\n\n**Remember:** The goal isn\'t just to make TypeScript happy—it\'s to write clear, maintainable, and correct code. When you encounter resistance from the type system, it often means the code structure needs fundamental improvement, not just type patches.\n\n## 🎯 TransformRealizeCoderHistories Integration\n\nWhen fixing Date-related errors in the TransformRealizeCoderHistories process:\n\n1. **Identify all Date-related compilation errors** in the error list\n2. **Apply systematic conversion** using `toISOStringSafe()` for all Date assignments\n3. **Verify field existence** in target types before assignment\n4. **Remove non-existent fields** rather than forcing assignments\n5. **Maintain type safety** by using `satisfies` with proper types\n\n## Critical Reminders\n\n- **NEVER use `as any` or type assertions** to bypass Date type errors\n- **ALWAYS convert Date objects to ISO strings** before assignment\n- **Prisma DateTime fields are stored as ISO strings**, not Date objects\n- **All date fields in API structures use `string & tags.Format<\'date-time\'>`**\n- **Handle nullable dates with proper null checking** using `toISOStringSafe()` with conditional logic\n\nThis systematic approach ensures that all Date-related TypeScript errors are resolved correctly while maintaining type safety and consistency across the codebase.\n\n# Typia Guide\n\nWhen defining validation rules for input or response structures using `typia`, you **must** utilize `tags` exclusively through the `tags` namespace provided by the `typia` module. This ensures strict type safety, clarity, and compatibility with automated code generation and schema extraction.\nFor example, to use `tags.Format<\'uuid\'>`, you must reference it as `tags.Format`, not simply `Format`.\n\n## ✅ Correct Usage Examples\n\n```ts\nexport interface IUser {\n  username: string & tags.MinLength<3> & tags.MaxLength<20>;\n  email: string & tags.Format<"email">;\n  age: number & tags.Type<"uint32"> & tags.Minimum<18>;\n}\n```\n\n## ❌ Invalid Usage Examples\n\n```ts\nexport interface IUser {\n  username: string & MinLength<3> & MaxLength<20>;\n  email: string & Format<"email">;\n  age: number & Type<"uint32"> & Minimum<18>;\n}\n```\n\n---\n\n## 🛡️ Advanced Type Narrowing and Casting Patterns\n\n**IMPORTANT**: Following patterns help resolve TypeScript type casting and assignment errors safely without causing infinite recursive type issues.\n\n### 🎯 The satisfies Pattern for Typia Tag Mismatches\n\nWhen encountering Typia tag type incompatibility errors (`"typia.tag"` in error message), use the `satisfies` pattern to strip tags while preserving base types:\n\n**THE FOUR-STEP FIX:**\n1. **See tag mismatch error?** → Identify the type mismatch\n2. **Check if nullable** → 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   - **Nullish coalescing:** `(value ?? default) satisfies BaseType as BaseType` (ALWAYS use parentheses)\n\n```typescript\n// Problem: Tag mismatch between different constraints\nconst page: number & tags.Type<"int32"> = getValue();\nconst pageWithMinimum: number & tags.Type<"int32"> & tags.Minimum<0> = page; // ERROR!\n\n// Solution: Strip tags using satisfies pattern\nconst pageWithMinimum: number & tags.Type<"int32"> & tags.Minimum<0> = \n  page satisfies number as number;\n\n// With nullable types\nconst userId: (string & tags.Format<"uuid">) | null | undefined = getId();\nconst simpleId: string | null | undefined = \n  userId satisfies string | null | undefined as string | null | undefined;\n\n// With nullish coalescing - ALWAYS wrap in parentheses\nconst x: (number & tags.Type<"int32">) | null | undefined = getValue();\nconst y: number & tags.Type<"int32"> & tags.Minimum<0> = \n  (x ?? 0) satisfies number as number;\n```\n\n### 📅 Date to String Conversions\n\nAlways use `.toISOString()` when converting Date to string types:\n\n```typescript\n// ❌ ERROR: Cannot assign Date to string\nconst date: Date = new Date();\nconst timestamp: string & tags.Format<"date-time"> = date; // ERROR!\n\n// ✅ CORRECT: Convert Date to ISO string\nconst timestamp: string & tags.Format<"date-time"> = date.toISOString();\n\n// Handling nullable dates\nconst date: Date | null | undefined = getDate();\nconst timestamp: string | null | undefined = date?.toISOString() ?? null;\n\n// Providing default for non-nullable target\nconst timestamp: string = (date ?? new Date()).toISOString();\n```\n\n### 🔍 Exhaustive Nullable/Undefined Type Narrowing\n\nTypeScript requires explicit elimination of each union member:\n\n**THE PATTERN:**\n1. **See `T | null | undefined`?** → Write `!== null && !== undefined`\n2. **See `T | undefined`?** → Write `!== undefined`\n3. **See `T | null`?** → Write `!== null`\n\n```typescript\n// Problem: Incomplete type narrowing\nconst value: string | null | undefined = getValue();\nif (value !== null) {\n  processString(value); // ERROR: value is still string | undefined\n}\n\n// Solution: Exhaustive checking\nif (value !== null && value !== undefined) {\n  processString(value); // OK: value is string\n}\n\n// Converting null to undefined (common with Prisma)\nconst dbValue: string | null = getFromDatabase();\nconst apiValue: string | undefined = dbValue !== null ? dbValue : undefined;\n\n// Or using nullish coalescing\nconst apiValue: string | undefined = dbValue ?? undefined;\n```\n\n### 🔤 String to Literal Union Type Narrowing\n\nFor literal type assignments, use type assertions when confident:\n\n```typescript\n// Problem: Cannot assign string to literal union\nconst status: string = getStatus();\nconst validStatus: "pending" | "approved" | "rejected" = status; // ERROR!\n\n// Solution: Type assertion\nconst validStatus: "pending" | "approved" | "rejected" = \n  status as "pending" | "approved" | "rejected";\n\n// With runtime validation using custom type guard\nfunction isValidStatus(s: string): s is "pending" | "approved" | "rejected" {\n  return ["pending", "approved", "rejected"].includes(s);\n}\n\nif (isValidStatus(status)) {\n  // status is now typed as literal union\n}\n```\n\n### ⛓️ Optional Chaining with Boolean Results\n\nOptional chaining with array methods returns `T | undefined`, not pure boolean:\n\n```typescript\n// Problem: Optional chaining creates boolean | undefined\nconst hasBlogTag = article.tags?.includes("blog"); // Type: boolean | undefined\nTestValidator.predicate("has tag", hasBlogTag); // ERROR: expects boolean\n\n// Solution 1: Compare with true (RECOMMENDED)\nTestValidator.predicate(\n  "has tag", \n  article.tags?.includes("blog") === true\n);\n\n// Solution 2: Use nullish coalescing\nTestValidator.predicate(\n  "has tag",\n  article.tags?.includes("blog") ?? false\n);\n```\n\n### 🚫 Type Narrowing "No Overlap" Errors\n\nWhen TypeScript says types have "no overlap", remove redundant checks:\n\n```typescript\n// Problem: Redundant type check after narrowing\nif (value === false) {\n  handleFalse();\n} else {\n  if (value !== false) { // ERROR: \'true\' and \'false\' have no overlap\n    handleTrue();\n  }\n}\n\n// Solution: Remove redundant check\nif (value === false) {\n  handleFalse();\n} else {\n  handleTrue(); // value must be true here\n}\n```\n\n### 🎯 Safe Type Handling Patterns Summary\n\n```typescript\n// Custom type guard for complex validation\nfunction isUser(obj: unknown): obj is IUser {\n  return typeof obj === \'object\' && \n         obj !== null && \n         \'username\' in obj &&\n         \'email\' in obj;\n}\n\n// Type assertion when confident\nconst user = input as IUser;\n\n// Conditional narrowing for safety\nif (isUser(input)) {\n  console.log(input.username); // Safe access\n}\n```\n\n\n### Handling Type Errors for JsonSchemaPlugin Format Mismatches\n\n- These errors occur because a value typed as `number & Type<"int32">` is being assigned where `number & Type<"int32"> & typia.tags.JsonSchemaPlugin<{ format: "uint32" }>` is expected.\n- The root cause is a mismatch between signed (`int32`) and unsigned (`uint32`) integer formats.\n- To resolve these, use type assertions or ensure proper type compatibility.\n- Example:\n\n```ts\nconst value = getValue() as number & tags.Type<"int32"> & tags.JsonSchemaPlugin<{ format: "uint32" }>;\n\n// Value is now typed correctly\n```\n\n* Use type assertions carefully to satisfy TypeScript\'s type checker.\n* This approach ensures type safety when you\'re confident about the value.\n\n---\n\n### ✅ Summary: Type Handling Best Practices\n\n| Use Case                             | Recommended Approach     |\n| ------------------------------------ | ------------------------ |\n| Type assertion when confident        | `as T`                   |\n| Runtime validation needed            | Custom type guards       |\n| Safe type narrowing                  | Conditional checks       |\n| Complex validation logic             | Helper functions         |\n\n> **Note:** Avoid using typia.assert or typia.assertGuard with Prisma types to prevent infinite recursive type issues.\n\n---\n\n## 🏷️ Typia Tags Declaration – Explanation & Usage Guide\n\nYou can use the following tags from Typia to annotate your types for additional semantic meaning, validation constraints, or schema generation.\n\n| Tag                | Purpose                                                                                                                                                                         |\n| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `Constant`         | Enforces the value to be a specific constant. Useful for literal values.<br>→ `string & tags.Constant<\'active\'>`                                                                |\n| `ContentMediaType` | Specifies the media type of content (e.g., `application/json`, `text/plain`).                                                                                                   |\n| `Default`          | Declares a default value to be used when the field is not provided.<br>**Note:** This is a schema-level hint, not runtime logic.                                                |\n| `Example`          | Declares a single example value to help with documentation tools like Swagger.                                                                                                  |\n| `Examples`         | Declares multiple example values.                                                                                                                                               |\n| `ExclusiveMaximum` | Similar to `Maximum`, but the value must be **strictly less than** the given limit.                                                                                             |\n| `ExclusiveMinimum` | Similar to `Minimum`, but the value must be **strictly greater than** the given limit.                                                                                          |\n| `Format`           | Specifies a semantic format for a value, such as:<br>→ `email`, `uuid`, `date-time`, `url`, etc.<br>✅ Used heavily across our codebase.<br>e.g., `string & tags.Format<\'uuid\'>` |\n| `JsonSchemaPlugin` | Allows adding plugin-specific schema behaviors. Rarely needed.                                                                                                                  |\n| `Maximum`          | Specifies the maximum value (inclusive) for a number.<br>e.g., `number & tags.Maximum<100>`                                                                                     |\n| `MaxItems`         | Specifies the maximum number of elements in an array.                                                                                                                           |\n| `MaxLength`        | Specifies the maximum string length.<br>e.g., `string & tags.MaxLength<50>`                                                                                                     |\n| `Minimum`          | Specifies the minimum value (inclusive) for a number.                                                                                                                           |\n| `MinItems`         | Specifies the minimum number of array items.                                                                                                                                    |\n| `MinLength`        | Specifies the minimum string length.                                                                                                                                            |\n| `MultipleOf`       | The value must be a multiple of the given number.<br>e.g., `number & tags.MultipleOf<5>`                                                                                        |\n| `Pattern`          | Applies a regular expression pattern to a string.<br>e.g., `string & tags.Pattern<\'^[a-z]+>`                                                                                  |\n| `Sequence`         | Used for sequential fields like auto-incrementing IDs.                                                                                                                          |\n| `TagBase`          | Internal utility tag – typically not used directly.                                                                                                                             |\n| `Type`             | Used to enforce a type name in JSON Schema generation.                                                                                                                          |\n| `UniqueItems`      | Ensures all elements in an array are unique.                                                                                                                                    |\n\n---\n\n### ✅ Examples\n\n```ts\ntype UserId = string & tags.Format<\'uuid\'>;\ntype LimitedString = string & tags.MinLength<5> & tags.MaxLength<20>;\ntype SmallNumber = number & tags.Minimum<1> & tags.Maximum<10>;\ntype ConstantStatus = string & tags.Constant<\'active\'>;\ntype Email = string & tags.Format<\'email\'>;\n```\n\n---\n\n### 🔒 Typia Tag Usage Notes\n\n* Tags are used at the **type level**, not runtime.\n* They are especially useful when:\n  - Generating OpenAPI/JSON Schema documentation\n  - Validating input data with strict constraints\n  - Ensuring type safety for specific formats (email, uuid, etc.)\n\n---\n\n## 🚨 CRITICAL: Prisma ID Field Handling\n\n### Primary Key (ID) Field Requirements\n\nWhen creating records with Prisma, you MUST carefully check the schema for ID field configuration:\n\n1. **Check ID Field Definition**: Look for `@id` or `@@id` annotations in the Prisma schema\n2. **Check for Auto-Generation**: Look for these patterns:\n   - `@default(autoincrement())` - Auto-incrementing ID (DO NOT provide ID)\n   - `@default(uuid())` - Auto-generated UUID (DO NOT provide ID)\n   - `@default(cuid())` - Auto-generated CUID (DO NOT provide ID)\n   - `@default(dbgenerated())` - Database-generated ID (DO NOT provide ID)\n   - No `@default()` - **YOU MUST PROVIDE THE ID VALUE**\n\n3. **🚨 MANDATORY for Data Creation**: \n   - **ALWAYS verify if the primary key has a default value before creating data**\n   - This is a CRITICAL check that must be performed in every create operation\n   - If no default exists, you MUST generate and provide the ID using `v4()`:\n     ```typescript\n     // When schema shows: id String @id (no default)\n     const created = await MyGlobal.prisma.someModel.create({\n       data: {\n         id: v4() as string & tags.Format<"uuid">, // REQUIRED when no @default!\n         // ... other fields\n       }\n     });\n     ```\n   - If default exists, NEVER provide the ID:\n     ```typescript\n     // When schema shows: id String @id @default(uuid())\n     const created = await MyGlobal.prisma.someModel.create({\n       data: {\n         // DO NOT include id field - it\'s auto-generated\n         // ... other fields\n       }\n     });\n     ```\n\n### ❌ Common Mistake - Missing Required ID\n\n```typescript\n// ❌ WRONG - Missing required ID when schema has no default\nconst created = await MyGlobal.prisma.discussion_board_warnings.create({\n  data: {\n    member_id: body.member_id,\n    moderator_id: body.moderator_id,\n    warning_type: body.warning_type,\n    message: body.message,\n    created_at: toISOStringSafe(body.created_at),\n  },\n});\n```\n\n### ✅ Correct - Including Required ID\n\n```typescript\n// ✅ CORRECT - Including ID when schema has no default\nconst created = await MyGlobal.prisma.discussion_board_warnings.create({\n  data: {\n    id: body.id, // REQUIRED when schema has no @default\n    member_id: body.member_id,\n    moderator_id: body.moderator_id,\n    warning_type: body.warning_type,\n    message: body.message,\n    created_at: toISOStringSafe(body.created_at),\n  },\n});\n```\n\n### Schema Analysis Checklist\n\nBefore implementing any Prisma create operation:\n\n1. **Examine the model\'s ID field**:\n   ```prisma\n   model discussion_board_warnings {\n     id String @id  // No @default() = YOU MUST PROVIDE ID\n     // vs\n     id String @id @default(uuid())  // Has default = DO NOT PROVIDE ID\n   }\n   ```\n\n2. **Apply the rule**:\n   - Has `@default()` → Prisma generates ID automatically\n   - No `@default()` → You MUST include `id` in the create data\n\n3. **Verify composite keys**: If using `@@id([field1, field2])`, all composite key fields must be provided\n\n### 🔴 ABSOLUTE RULE: Always Check Prisma Schema for ID Configuration\n\n**NEVER ASSUME** an ID field is auto-generated. **ALWAYS VERIFY** by checking the Prisma schema for the presence of `@default()` annotation on the ID field. This is a frequent source of runtime errors.\n\n---\n\n## 🚨 CRITICAL: Prisma OrderBy Inline Usage\n\n### Never Extract orderBy as a Variable\n\nWhen using Prisma\'s `orderBy` parameter, **ALWAYS** define it inline within the query. Extracting it as a variable often causes TypeScript type inference issues.\n\n### ❌ Common Mistake - Extracting orderBy\n\n```typescript\n// ❌ WRONG - Extracting orderBy as a variable causes type errors\nconst orderBy = \n  sort === "created_at"\n    ? { created_at: order === "asc" ? "asc" : "desc" }\n    : { created_at: "desc" };\n\nconst [rows, total] = await Promise.all([\n  MyGlobal.prisma.discussion_board_attachments.findMany({\n    where,\n    orderBy, // Type error prone!\n    skip,\n    take: pageSize,\n  }),\n  MyGlobal.prisma.discussion_board_attachments.count({ where }),\n]);\n```\n\n### ✅ Correct - Inline orderBy Definition\n\n```typescript\n// ✅ CORRECT - Define orderBy inline for proper type inference\nconst [rows, total] = await Promise.all([\n  MyGlobal.prisma.discussion_board_attachments.findMany({\n    where,\n    orderBy: sort === "created_at"\n      ? { created_at: order === "asc" ? "asc" : "desc" }\n      : { created_at: "desc" },\n    skip,\n    take: pageSize,\n  }),\n  MyGlobal.prisma.discussion_board_attachments.count({ where }),\n]);\n```\n\n### Why This Matters\n\n1. **Type Inference**: Prisma uses complex generic types that work best with inline definitions\n2. **Type Safety**: Extracting orderBy can lose the connection between the model and the ordering fields\n3. **Maintenance**: Inline definitions are clearer about which fields can be ordered\n\n### 🔴 ABSOLUTE RULE: Always Define orderBy Inline\n\n**NEVER** extract `orderBy` as a separate variable. **ALWAYS** define it inline within the Prisma query options. This prevents type errors and ensures proper TypeScript inference.\n\n> ⚠️ **Never use these tags directly for logic branching in code.** They are strictly for static type and schema purposes.'
     }, ...authorizationHistories, {
         id: v7(),
         created_at: (new Date).toISOString(),
@@ -25848,7 +25906,7 @@ function transformRealizeCorrectHistories(props) {
     })), {
         id: v7(),
         type: "systemMessage",
-        text: "\x3c!--\nfilename: REALIZE_CORRECT.md\n--\x3e\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## 🎯 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### 📝 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### ⚡ 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### 🔧 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.\n\n## Output Format (Chain of Thinking)\n\nYou must return a structured output following the `IAutoBeRealizeCorrectApplication.IProps` interface. This interface contains all necessary fields for the correction process within a `revise` object. Each field in the `revise` object represents a phase in your error correction process:\n\n```typescript\nexport namespace IAutoBeRealizeCorrectApplication {\n  export interface IProps {\n    revise: {\n      errorAnalysis?: string;           // Step 1: TypeScript compilation error analysis (OPTIONAL)\n      plan?: string;                    // Step 2: Implementation plan (OPTIONAL)\n      prismaSchemas?: string;           // Step 3: Relevant schema definitions (OPTIONAL)\n      review?: string;                  // Step 4: Refined version (OPTIONAL)\n      final: string;                    // Step 5: Final implementation (REQUIRED)\n    }\n  }\n}\n```\n\n### 📝 FIELD REQUIREMENTS: OPTIONAL STEPS FOR EFFICIENCY\n\n**NEW APPROACH**: Most fields are now OPTIONAL to allow efficient correction when errors are obvious.\n\n**REQUIRED FIELD:**\n- `revise.final`: MUST contain complete, valid TypeScript function code\n\n**⚡ OPTIONAL FIELDS - Skip When Obvious:**\n- `revise.errorAnalysis`: Skip if error is trivial (e.g., simple null handling)\n- `revise.plan`: Skip if fix is straightforward\n- `revise.prismaSchemas`: Skip if schema context is clear from error\n- `revise.review`: Skip if no complex logic to review\n\n**🎯 WHEN TO SKIP STEPS:**\n\n**Skip intermediate steps for:**\n- Simple type mismatches (null → 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**Use full Chain of Thinking for:**\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  revise: {\n    final: `\n      // ... fixed code with device_info: updated.device_info ?? \"\" ...\n    `\n    // Other fields omitted as fix is obvious\n  }\n}\n```\n\n### Field Descriptions\n\n#### 📊 revise.errorAnalysis (Step 1 - OPTIONAL - CoT: Problem Identification)\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**📊 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**🛠 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**📝 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**🎯 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   - ⚠️ CRITICAL: toISOStringSafe CANNOT handle null! Always check first:\n     ```typescript\n     // ❌ WRONG: Will crash if value is null\n     toISOStringSafe(value)\n     \n     // ✅ CORRECT: Check null first\n     value ? toISOStringSafe(value) : null\n     ```\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 (Step 2 - OPTIONAL - CoT: Strategy Formation)\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 (Step 3 - OPTIONAL - CoT: Context Re-establishment)\n\n**Prisma Schema String**\n\nContains ONLY the relevant models and fields used in this implementation.\n\n#### revise.review (Step 4 - OPTIONAL - CoT: Improvement Phase)\n\n**Refined Version**\n\nImproved version with real operations and error handling.\n\n#### 💻 revise.final (Step 5 - REQUIRED - CoT: Complete Solution)\n\n**Final Implementation**\n\nComplete, error-free TypeScript function implementation following all conventions.\n\n**🚨 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## 🔄 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 hashing libraries\n- The missing function should already exist in the codebase\n\n### Type Assignment Patterns\nIf you see the same type assignment error pattern:\n1. Identify the conversion needed (e.g., `string` → enum)\n2. Apply the SAME conversion pattern to ALL similar cases\n\n## 🚨🚨🚨 MOST VIOLATED RULE - NEVER USE hasOwnProperty 🚨🚨🚨\n\n**ABSOLUTELY FORBIDDEN - AI KEEPS VIOLATING THIS:**\n```typescript\n// ❌ NEVER USE THESE PATTERNS:\nObject.prototype.hasOwnProperty.call(body, \"field\")  // FORBIDDEN!\nbody.hasOwnProperty(\"field\")                         // FORBIDDEN!\n```\n\n**✅ 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**This is the MOST VIOLATED RULE - DO NOT USE hasOwnProperty EVER!**\n\n## 🚨 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**🎯 SUPER SIMPLE FIX - Just Remove or Rename the Field!**\n\n**⚠️ COMMON NAMING ERROR PATTERNS (Examples from Production):**\n```typescript\n// These are EXAMPLES - actual field names vary by project\n// Pattern: Wrong Field Name → Typical Correct Pattern\n\n// Example: User type field confusion\n'seller_user_id'    → Often should be 'user_id' or 'member_id'\n'guest_user_id'     → Often should be 'user_id' or removed entirely\n'admin_user_id'     → Often maps to a common user field\n\n// Example: Soft delete fields that often don't exist\n'deleted_at'        → Usually doesn't exist - remove or use hard delete\n'is_deleted'        → Check if soft delete is actually in schema\n\n// Example: Naming convention mismatches  \n'userId'            → Might be 'user_id' (snake_case)\n'created_by'        → 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**🔥 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// ❌ 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// ✅ 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├── Is field in Prisma schema?\n│   ├── NO → DELETE the field from query\n│   └── YES → You typed wrong name, fix it\n└── Done! Error fixed!\n```\n\n**🚨 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**🎯 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,        // ❌ Field doesn't exist!\n    guest_user_id: userId    // ❌ 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               // ✅ 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          // ✅ 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**🔄 Quick Fix Pattern**:\n1. See field error in WHERE clause → Remove the field completely\n2. Business logic still needs to work → Adjust logic without that field\n3. Don't create workarounds → 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 → 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**🚨 CRITICAL RULE FOR NULL/UNDEFINED:**\n- `field?: Type` means OPTIONAL → use `undefined` when missing, NEVER `null`\n- `field: Type | null` means REQUIRED NULLABLE → use `null` when empty, NEVER `undefined`\n- `field?: Type | null` means OPTIONAL + NULLABLE → 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**Nullable to Required Conversion (Most Common)**\n```typescript\n// ERROR: Type 'string | null' is not assignable to type 'string'\n// Prisma schema: ip_address: string | null\n// API interface: ip_address: string\n\n// WRONG: Trying to assign nullable directly\nreturn {\n  ip_address: created.ip_address,  // ERROR: string | null not assignable to string\n};\n\n// CORRECT: Provide default value for null case\nreturn {\n  ip_address: created.ip_address ?? \"\",      // Converts null to empty string\n  device_info: created.device_info ?? \"\",    // Same pattern for all nullable fields\n  port_number: created.port_number ?? 0,     // Number fields use 0 as default\n  is_active: created.is_active ?? false,     // Boolean fields use false as default\n};\n```\n\n**Resolution Priority:**\n1. **Use defaults when possible**: `?? \"\"` for strings, `?? 0` for numbers, `?? false` for booleans\n2. **Document if interface seems wrong**: Sometimes interface incorrectly requires non-nullable\n3. **Use typia.random only as last resort**: When field doesn't exist at all in schema\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**🚨 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**🚨 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// ❌ 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// ❌ 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### 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**⚠️ CRITICAL: `satisfies` DOESN'T work for string → 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// ❌ 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// ✅ 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// ✅ Pattern 2: Type assertion when confident\nconst sortField = body.sort.replace(/^[-+]/, \"\") as \"name\" | \"created_at\";\n\n// ✅ 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 → Number\nconst num = parseInt(str, 10);\n\n// String → Date  \nconst date = new Date(str);\n\n// String → Boolean\nconst bool = str === 'true';\n\n// Array → Single\nconst [item] = await prisma.findMany({ where, take: 1 });\nreturn item || null;\n```\n\n## 🛑 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├── YES → Proceed to Step 3\n└── NO → 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## 🚫 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\n8. **NEVER** prioritize comments over types - types are the source of truth\n\n## ⚡ 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 → 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   // ❌ REDUNDANT: Function already has return type\n   async function getUser(): Promise<IUser> {\n     return { ... } satisfies IUser;  // Unnecessary!\n   }\n   \n   // ✅ 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## 📊 Quick Reference Table\n\n| Error Code | Common Cause | First Try | If Fails |\n|------------|-------------|-----------|----------|\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## 🏛️ Database Engine Compatibility\n\n**🚨 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\"  // ← 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## 🎯 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## 🆘 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` → Usually doesn't exist, remove it\n     - `seller_user_id` → 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├── \"doesn't exist\" → DELETE it\n├── \"not assignable to '[]'\" → Return actual array type\n├── \"null not assignable\" → Add ?? \"\"\n└── Still confused? → Use full CoT analysis\n```\n\n## 📊 Decision Tree for Correction Approach\n\n```\nError Complexity Assessment:\n├── Simple (single line, obvious fix)\n│   └── Skip to final only\n├── Medium (2-3 related errors)\n│   └── Use errorAnalysis + final\n└── Complex (multiple files, nested errors)\n    └── Use full Chain of Thinking\n\nCommon Simple Fixes (skip CoT):\n- Type 'string | null' not assignable → Add ?? \"\"\n- Property doesn't exist → Remove it\n- Array [] type mismatch → Use correct array type\n- Date type issues → Use toISOStringSafe()\n- Missing await → Add await\n- Wrong parameter count → Fix arguments\n```\n\n## 💡 Real Examples\n\n### Example 1: Simple Null Handling (Skip CoT)\n**Error**: `Type 'string | null' is not assignable to type 'string'`\n```typescript\n// Just provide fixed code in final\n{\n  revise: {\n    final: `\n      export async function updateUser(...) {\n        // ...\n        return {\n          device_info: updated.device_info ?? \"\",  // Fixed\n          ip_address: updated.ip_address ?? \"\",    // Fixed\n          // ...\n        };\n      }\n    `\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  revise: {\n    errorAnalysis: \"Multiple cascading errors due to missing relation...\",\n    plan: \"Need to restructure queries to avoid nested operations...\",\n    prismaSchemas: \"model User { ... }\",\n    // ... other steps ...\n    final: \"// Complete refactored solution\"\n  }\n}\n```\n\n## 🎯 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",
+        text: '\x3c!--\nfilename: REALIZE_CORRECT.md\n--\x3e\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## 🎯 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### 📝 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### ⚡ 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### 🔧 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.\n\n## Output Format (Chain of Thinking)\n\nYou must return a structured output following the `IAutoBeRealizeCorrectApplication.IProps` interface. This interface contains all necessary fields for the correction process within a `revise` object. Each field in the `revise` object represents a phase in your error correction process:\n\n```typescript\nexport namespace IAutoBeRealizeCorrectApplication {\n  export interface IProps {\n    revise: {\n      errorAnalysis?: string;           // Step 1: TypeScript compilation error analysis (OPTIONAL)\n      plan?: string;                    // Step 2: Implementation plan (OPTIONAL)\n      prismaSchemas?: string;           // Step 3: Relevant schema definitions (OPTIONAL)\n      review?: string;                  // Step 4: Refined version (OPTIONAL)\n      final: string;                    // Step 5: Final implementation (REQUIRED)\n    }\n  }\n}\n```\n\n### 📝 FIELD REQUIREMENTS: OPTIONAL STEPS FOR EFFICIENCY\n\n**NEW APPROACH**: Most fields are now OPTIONAL to allow efficient correction when errors are obvious.\n\n**REQUIRED FIELD:**\n- `revise.final`: MUST contain complete, valid TypeScript function code\n\n**⚡ OPTIONAL FIELDS - Skip When Obvious:**\n- `revise.errorAnalysis`: Skip if error is trivial (e.g., simple null handling)\n- `revise.plan`: Skip if fix is straightforward\n- `revise.prismaSchemas`: Skip if schema context is clear from error\n- `revise.review`: Skip if no complex logic to review\n\n**🎯 WHEN TO SKIP STEPS:**\n\n**Skip intermediate steps for:**\n- Simple type mismatches (null → 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**Use full Chain of Thinking for:**\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  revise: {\n    final: `\n      // ... fixed code with device_info: updated.device_info ?? "" ...\n    `\n    // Other fields omitted as fix is obvious\n  }\n}\n```\n\n### Field Descriptions\n\n#### 📊 revise.errorAnalysis (Step 1 - OPTIONAL - CoT: Problem Identification)\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**📊 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**🛠 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**📝 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**🎯 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   - ⚠️ CRITICAL: toISOStringSafe CANNOT handle null! Always check first:\n     ```typescript\n     // ❌ WRONG: Will crash if value is null\n     toISOStringSafe(value)\n     \n     // ❌ 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     // ✅ CORRECT: Use ternary operator (? :) for null checking with toISOStringSafe\n     deleted_at: user.deleted_at ? toISOStringSafe(user.deleted_at) : null\n     \n     // ✅ CORRECT: General pattern for nullable date fields\n     created_at: user.created_at ? toISOStringSafe(user.created_at) : null\n     updated_at: user.updated_at ? toISOStringSafe(user.updated_at) : 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 (Step 2 - OPTIONAL - CoT: Strategy Formation)\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 (Step 3 - OPTIONAL - CoT: Context Re-establishment)\n\n**Prisma Schema String**\n\nContains ONLY the relevant models and fields used in this implementation.\n\n#### revise.review (Step 4 - OPTIONAL - CoT: Improvement Phase)\n\n**Refined Version**\n\nImproved version with real operations and error handling.\n\n#### 💻 revise.final (Step 5 - REQUIRED - CoT: Complete Solution)\n\n**Final Implementation**\n\nComplete, error-free TypeScript function implementation following all conventions.\n\n**🚨 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## 🔄 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 hashing libraries\n- The missing function should already exist in the codebase\n\n### Type Assignment Patterns\nIf you see the same type assignment error pattern:\n1. Identify the conversion needed (e.g., `string` → enum)\n2. Apply the SAME conversion pattern to ALL similar cases\n\n## 🚨🚨🚨 MOST VIOLATED RULE - NEVER USE hasOwnProperty 🚨🚨🚨\n\n**ABSOLUTELY FORBIDDEN - AI KEEPS VIOLATING THIS:**\n```typescript\n// ❌ NEVER USE THESE PATTERNS:\nObject.prototype.hasOwnProperty.call(body, "field")  // FORBIDDEN!\nbody.hasOwnProperty("field")                         // FORBIDDEN!\n```\n\n**✅ 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**This is the MOST VIOLATED RULE - DO NOT USE hasOwnProperty EVER!**\n\n## 🚨 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**🎯 SUPER SIMPLE FIX - Just Remove or Rename the Field!**\n\n**⚠️ COMMON NAMING ERROR PATTERNS (Examples from Production):**\n```typescript\n// These are EXAMPLES - actual field names vary by project\n// Pattern: Wrong Field Name → Typical Correct Pattern\n\n// Example: User type field confusion\n\'seller_user_id\'    → Often should be \'user_id\' or \'member_id\'\n\'guest_user_id\'     → Often should be \'user_id\' or removed entirely\n\'admin_user_id\'     → Often maps to a common user field\n\n// Example: Soft delete fields that often don\'t exist\n\'deleted_at\'        → Usually doesn\'t exist - remove or use hard delete\n\'is_deleted\'        → Check if soft delete is actually in schema\n\n// Example: Naming convention mismatches  \n\'userId\'            → Might be \'user_id\' (snake_case)\n\'created_by\'        → 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**🔥 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// ❌ 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// ✅ 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├── Is field in Prisma schema?\n│   ├── NO → DELETE the field from query\n│   └── YES → You typed wrong name, fix it\n└── Done! Error fixed!\n```\n\n**🚨 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**🎯 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,        // ❌ Field doesn\'t exist!\n    guest_user_id: userId    // ❌ 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               // ✅ 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          // ✅ 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**🔄 Quick Fix Pattern**:\n1. See field error in WHERE clause → Remove the field completely\n2. Business logic still needs to work → Adjust logic without that field\n3. Don\'t create workarounds → 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 → 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**🚨 CRITICAL RULE FOR NULL/UNDEFINED:**\n- `field?: Type` means OPTIONAL → use `undefined` when missing, NEVER `null`\n- `field: Type | null` means REQUIRED NULLABLE → use `null` when empty, NEVER `undefined`\n- `field?: Type | null` means OPTIONAL + NULLABLE → 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**Nullable to Required Conversion (Most Common)**\n```typescript\n// ERROR: Type \'string | null\' is not assignable to type \'string\'\n// Prisma schema: ip_address: string | null\n// API interface: ip_address: string\n\n// WRONG: Trying to assign nullable directly\nreturn {\n  ip_address: created.ip_address,  // ERROR: string | null not assignable to string\n};\n\n// CORRECT: Provide default value for null case\nreturn {\n  ip_address: created.ip_address ?? "",      // Converts null to empty string\n  device_info: created.device_info ?? "",    // Same pattern for all nullable fields\n  port_number: created.port_number ?? 0,     // Number fields use 0 as default\n  is_active: created.is_active ?? false,     // Boolean fields use false as default\n};\n```\n\n**Resolution Priority:**\n1. **Use defaults when possible**: `?? ""` for strings, `?? 0` for numbers, `?? false` for booleans\n2. **Document if interface seems wrong**: Sometimes interface incorrectly requires non-nullable\n3. **Use typia.random only as last resort**: When field doesn\'t exist at all in schema\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**🚨 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**🚨 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// ❌ 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// ❌ 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### 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**⚠️ CRITICAL: `satisfies` DOESN\'T work for string → 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// ❌ 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// ✅ 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// ✅ Pattern 2: Type assertion when confident\nconst sortField = body.sort.replace(/^[-+]/, "") as "name" | "created_at";\n\n// ✅ 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 → Number\nconst num = parseInt(str, 10);\n\n// String → Date  \nconst date = new Date(str);\n\n// String → Boolean\nconst bool = str === \'true\';\n\n// Array → Single\nconst [item] = await prisma.findMany({ where, take: 1 });\nreturn item || null;\n```\n\n## 🛑 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├── YES → Proceed to Step 3\n└── NO → 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## 🚨 CRITICAL: Error Handling with HttpException\n\n**MANDATORY**: Always use HttpException for error handling:\n```typescript\n// ✅ 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// ❌ FORBIDDEN - Never use Error\nthrow new Error("Some error");  // FORBIDDEN!\n\n// ❌ 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// ✅ 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## 🚫 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\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\n\n## ⚡ 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 → 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   // ❌ REDUNDANT: Function already has return type\n   async function getUser(): Promise<IUser> {\n     return { ... } satisfies IUser;  // Unnecessary!\n   }\n   \n   // ✅ 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## 📊 Quick Reference Table\n\n| Error Code | Common Cause | First Try | If Fails |\n|------------|-------------|-----------|----------|\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## 🏛️ Database Engine Compatibility\n\n**🚨 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"  // ← 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## 🎯 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## 🆘 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` → Usually doesn\'t exist, remove it\n     - `seller_user_id` → 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├── "doesn\'t exist" → DELETE it\n├── "not assignable to \'[]\'" → Return actual array type\n├── "null not assignable" → Add ?? ""\n└── Still confused? → Use full CoT analysis\n```\n\n## 📊 Decision Tree for Correction Approach\n\n```\nError Complexity Assessment:\n├── Simple (single line, obvious fix)\n│   └── Skip to final only\n├── Medium (2-3 related errors)\n│   └── Use errorAnalysis + final\n└── Complex (multiple files, nested errors)\n    └── Use full Chain of Thinking\n\nCommon Simple Fixes (skip CoT):\n- Type \'string | null\' not assignable → Add ?? ""\n- Property doesn\'t exist → Remove it\n- Array [] type mismatch → Use correct array type\n- Date type issues → Use toISOStringSafe()\n- Missing await → Add await\n- Wrong parameter count → Fix arguments\n```\n\n## 💡 Real Examples\n\n### Example 1: Simple Null Handling (Skip CoT)\n**Error**: `Type \'string | null\' is not assignable to type \'string\'`\n```typescript\n// Just provide fixed code in final\n{\n  revise: {\n    final: `\n      export async function updateUser(...) {\n        // ...\n        return {\n          device_info: updated.device_info ?? "",  // Fixed\n          ip_address: updated.ip_address ?? "",    // Fixed\n          // ...\n        };\n      }\n    `\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  revise: {\n    errorAnalysis: "Multiple cascading errors due to missing relation...",\n    plan: "Need to restructure queries to avoid nested operations...",\n    prismaSchemas: "model User { ... }",\n    // ... other steps ...\n    final: "// Complete refactored solution"\n  }\n}\n```\n\n## 🎯 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',
         created_at: (new Date).toISOString()
     } ];
 }
@@ -25981,7 +26039,7 @@ async function correct$4(ctx, locations, scenarios, authorizations, functions, f
                 });
                 return {
                     ...func,
-                    content: correctEvent.content
+                    content: correctEvent === null ? "" : correctEvent.content
                 };
             } catch (err) {
                 return func;
@@ -25999,7 +26057,7 @@ async function step(ctx, props) {
     const dto = await getRealizeWriteDto(ctx, props.scenario.operation);
     const {tokenUsage} = await ctx.conversate({
         source: "realizeCorrect",
-        controller: createController$7({
+        controller: createController$8({
             model: ctx.model,
             build: next => {
                 pointer.value = next;
@@ -26019,7 +26077,9 @@ async function step(ctx, props) {
       Correct the TypeScript code implementation.
     `
     });
-    if (pointer.value === null) throw new Error("Failed to correct implementation code.");
+    if (pointer.value === null) {
+        return null;
+    }
     pointer.value.revise.final = await replaceImportStatements(ctx, {
         operation: props.scenario.operation,
         code: pointer.value.revise.final,
@@ -26040,9 +26100,9 @@ async function step(ctx, props) {
     return event;
 }
 
-function createController$7(props) {
+function createController$8(props) {
     assertSchemaModel(props.model);
-    const application = collection$8[props.model];
+    const application = collection$9[props.model];
     return {
         protocol: "class",
         name: "Write code",
@@ -26172,7 +26232,7 @@ const claude$3 = {
     } ]
 };
 
-const collection$8 = {
+const collection$9 = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -26366,7 +26426,7 @@ const correct$3 = async (ctx, authorizations, functions, failures, progress, eve
                 script: func.content,
                 diagnostics: dateErrors.filter(d => d.file === location)
             } ]),
-            controller: createController$6({
+            controller: createController$7({
                 model: ctx.model,
                 then: next => {
                     pointer.value = next;
@@ -26483,9 +26543,9 @@ const separateCorrectionResults = (corrections, errorLocations) => {
 
 const filterRelevantDiagnostics = (diagnostics, functionLocations) => diagnostics.filter(d => d.file && functionLocations.includes(d.file));
 
-const createController$6 = props => {
+const createController$7 = props => {
     assertSchemaModel(props.model);
-    const application = collection$7[props.model === "chatgpt" ? "chatgpt" : "claude"];
+    const application = collection$8[props.model === "chatgpt" ? "chatgpt" : "claude"];
     return {
         protocol: "class",
         name: "correctDateInvalidRequest",
@@ -26501,7 +26561,7 @@ const createController$6 = props => {
     };
 };
 
-const collection$7 = {
+const collection$8 = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -26757,7 +26817,7 @@ async function orchestrateRealizeWrite(ctx, props) {
             totalAuthorizations: props.totalAuthorizations,
             dto
         }),
-        controller: createController$5({
+        controller: createController$6({
             model: ctx.model,
             build: next => {
                 pointer.value = next;
@@ -26804,9 +26864,9 @@ async function orchestrateRealizeWrite(ctx, props) {
     return event;
 }
 
-function createController$5(props) {
+function createController$6(props) {
     assertSchemaModel(props.model);
-    const application = collection$6[props.model];
+    const application = collection$7[props.model];
     return {
         protocol: "class",
         name: "Write code",
@@ -26907,7 +26967,7 @@ const claude$2 = {
     } ]
 };
 
-const collection$6 = {
+const collection$7 = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -27058,16 +27118,17 @@ const orchestrateRealize = ctx => async props => {
         completed: 0
     };
     const writeEvents = await executeCachedBatch(scenarios.map(scenario => async promptCacheKey => {
-        const code = await orchestrateRealizeWrite(ctx, {
+        const props = {
             totalAuthorizations: authorizations,
             authorization: scenario.decoratorEvent ?? null,
             scenario,
             progress: writeProgress,
             promptCacheKey
-        });
+        };
+        const code = await orchestrateRealizeWrite(ctx, props).catch(() => orchestrateRealizeWrite(ctx, props).catch(() => null));
         return code;
     }));
-    const functions = Object.entries(Object.fromEntries(writeEvents.map(event => [ event.location, event.content ]))).map(([location, content]) => {
+    const functions = Object.entries(Object.fromEntries(writeEvents.filter(w => w !== null).map(event => [ event.location, event.content ]))).map(([location, content]) => {
         const scenario = scenarios.find(el => el.location === location);
         return {
             location,
@@ -27083,9 +27144,14 @@ const orchestrateRealize = ctx => async props => {
         total: writeEvents.length,
         completed: writeEvents.length
     };
-    const converted = await orchestrateRealizeCorrectCasting(ctx, authorizations, functions, reviewProgress, parseInt((ctx.retry / 2).toString()));
-    const correctedDate = await orchestrateRealizeCorrectDate(ctx, authorizations, converted, reviewProgress, parseInt((ctx.retry / 2).toString()));
-    const totalCorrected = await orchestrateRealizeCorrect(ctx, scenarios, authorizations, correctedDate, [], reviewProgress);
+    console.log("casting", reviewProgress);
+    const totalCorrected = await orchestrateRealizeCorrectCasting(ctx, authorizations, functions, reviewProgress).then(async res => {
+        console.log("date", reviewProgress);
+        return orchestrateRealizeCorrectDate(ctx, authorizations, res, reviewProgress).then(async res => {
+            console.log("correct", reviewProgress);
+            return orchestrateRealizeCorrect(ctx, scenarios, authorizations, res, [], reviewProgress);
+        });
+    });
     const compiler = await ctx.compiler();
     const controllers = await compiler.realize.controller({
         document: ctx.state().interface.document,
@@ -27133,7 +27199,7 @@ const correct$2 = async (ctx, factory, failures, script, event, life) => {
             diagnostics: e.result.diagnostics,
             script: factory.script(e)
         }))),
-        controller: createController$4({
+        controller: createController$5({
             model: ctx.model,
             then: next => {
                 pointer.value = next;
@@ -27162,9 +27228,9 @@ const correct$2 = async (ctx, factory, failures, script, event, life) => {
     return await predicate$2(ctx, factory, [ ...failures, event ], script, await factory.validate(pointer.value.revise.final), life - 1);
 };
 
-const createController$4 = props => {
+const createController$5 = props => {
     assertSchemaModel(props.model);
-    const application = collection$5[props.model === "chatgpt" ? "chatgpt" : "claude"];
+    const application = collection$6[props.model === "chatgpt" ? "chatgpt" : "claude"];
     return {
         protocol: "class",
         name: "correctInvalidRequest",
@@ -27180,7 +27246,7 @@ const createController$4 = props => {
     };
 };
 
-const collection$5 = {
+const collection$6 = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -27738,7 +27804,7 @@ const correct$1 = async (ctx, compile, write, event, life) => {
     const {tokenUsage} = await ctx.conversate({
         source: "testCorrect",
         histories: await transformTestCorrectInvalidRequestHistories(null, event.result.diagnostics),
-        controller: createController$3({
+        controller: createController$4({
             model: ctx.model,
             then: next => {
                 pointer.value = next;
@@ -27783,9 +27849,9 @@ const correct$1 = async (ctx, compile, write, event, life) => {
     return await predicate$1(ctx, compile, newWrite, newEvent, life - 1);
 };
 
-const createController$3 = props => {
+const createController$4 = props => {
     assertSchemaModel(props.model);
-    const application = collection$4[props.model === "chatgpt" ? "chatgpt" : "claude"];
+    const application = collection$5[props.model === "chatgpt" ? "chatgpt" : "claude"];
     return {
         protocol: "class",
         name: "correctInvalidRequest",
@@ -27801,7 +27867,7 @@ const createController$3 = props => {
     };
 };
 
-const collection$4 = {
+const collection$5 = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -28127,7 +28193,7 @@ const correct = async (ctx, content, failures, validate, promptCacheKey, life) =
             function: content,
             failure: validate.result
         } ]),
-        controller: createController$2({
+        controller: createController$3({
             model: ctx.model,
             failure: validate.result,
             build: next => {
@@ -28170,7 +28236,7 @@ const correct = async (ctx, content, failures, validate, promptCacheKey, life) =
     } ], newValidate, promptCacheKey, life);
 };
 
-const createController$2 = props => {
+const createController$3 = props => {
     assertSchemaModel(props.model);
     const validate = input => {
         const result = (() => {
@@ -28236,7 +28302,7 @@ const createController$2 = props => {
         })()(input);
         return result;
     };
-    const application = collection$3[props.model === "chatgpt" ? "chatgpt" : "claude"](validate);
+    const application = collection$4[props.model === "chatgpt" ? "chatgpt" : "claude"](validate);
     return {
         protocol: "class",
         name: "correct",
@@ -28249,7 +28315,7 @@ const createController$2 = props => {
     };
 };
 
-const collection$3 = {
+const collection$4 = {
     chatgpt: validate => (() => {
         const application = {
             model: "chatgpt",
@@ -28640,18 +28706,902 @@ const transformTestScenarioHistories = (state, document, include, exclude) => {
     } ];
 };
 
-async function orchestrateTestScenario(ctx) {
+function transformTestScenarioReviewHistories(ctx, groups) {
     const document = ctx.state().interface?.document;
     if (document === undefined) {
-        throw new Error("Cannot write test scenarios because these are no operations.");
+        throw new Error("Cannot review test scenarios because there are no operations.");
     }
-    Object.entries(document.components.schemas);
-    const dict = new HashMap(document.operations.map(op => new Pair({
-        path: op.path,
-        method: op.method
-    }, op)), AutoBeEndpointComparator.hashCode, AutoBeEndpointComparator.equals);
-    const endpointNotFound = [ `You have to select one of the endpoints below`, "", " method | path ", "--------|------", ...document.operations.map(op => `\`${op.method}\` | \`${op.path}\``).join("\n") ].join("\n");
-    const progress = {
+    const relationships = document.operations.map(o => ({
+        endpoint: {
+            method: o.method,
+            path: o.path
+        },
+        ids: getReferenceIds({
+            document,
+            operation: o
+        })
+    })).filter(v => v.ids.length !== 0);
+    return [ {
+        id: v7(),
+        created_at: (new Date).toISOString(),
+        type: "systemMessage",
+        text: '\x3c!--\nfilename: TEST_SCENARIO_REVIEW.md\n--\x3e\n# Test Scenario Review System Prompt\n\nYou are a Test Scenario Review Agent responsible for validating and correcting test scenarios generated by the Test Scenario Agent. Your primary role is to ensure all test scenarios are complete, implementable, and follow proper dependency resolution patterns.\n\n## Available Information\n\nYou will receive:\n1. **Available API Operations** - Complete list of all API operations that exist\n2. **Test Scenario Groups** - The scenario groups to review, where each scenario includes a `requiredIds` field\n3. **Candidate Dependencies** - Table showing which endpoints require which IDs\n\n## MANDATORY VALIDATION CHECKLIST\n\nFor each scenario, you MUST complete this checklist in order:\n\n```\n□ Step 1: Extract ALL IDs from requiredIds array\n□ Step 2: For EACH ID, find creator operation in Available API Operations using ID mapping rules\n□ Step 3: Verify creator operation exists in current dependencies\n□ Step 4: If missing, ADD to dependencies list with proper purpose\n□ Step 5: RECURSIVE DEPENDENCY CHECK - For each creator operation, check Candidate Dependencies table for its own required IDs\n□ Step 6: Repeat Steps 2-5 until no more dependencies are found (complete the entire chain)\n□ Step 7: Remove duplicate operations (same method + path)\n□ Step 8: Add required authentication operations for all operations in the chain\n□ Step 9: Sort dependencies by execution order\n□ Step 10: FINAL COMPLETENESS VERIFICATION - Ensure entire execution path is covered\n□ Step 11: Verify all operations exist in Available API Operations\n```\n\n## STRICT ID → CREATOR MAPPING RULES\n\nApply these rules systematically to find creator operations:\n\n### Primary Mapping Strategy\n```\nID Pattern → Creator Operation Search\n- articleId → POST /articles\n- userId → POST /users OR POST /auth/user/join\n- categoryId → POST /categories\n- commentId → POST /articles/{articleId}/comments (nested resource)\n- orderId → POST /orders\n- productId → POST /products\n- reviewId → POST /products/{productId}/reviews (nested resource)\n```\n\n### Search Algorithm (Apply in Order)\n```\nFOR EACH required_id IN requiredIds:\n  1. Extract entity name: remove "Id" suffix (articleId → article)\n  2. Search for POST /{entities} (plural form)\n  3. If not found, search for POST /{entity} (singular form)  \n  4. If not found, search for nested creation: POST /parent/{parentId}/{entities}\n  5. For user-related IDs, also check POST /auth/{role}/join\n  6. IF creator_operation found AND creator_operation NOT IN current_dependencies:\n       ADD creator_operation TO dependencies\n  7. IF creator_operation NOT found:\n       FLAG as external/pre-existing resource\nEND FOR\n```\n\n## COMPREHENSIVE DEPENDENCY COMPLETENESS VERIFICATION\n\n### CRITICAL REQUIREMENT: Complete Dependency Chain Analysis\n\nBefore passing any scenario, you MUST verify that the ENTIRE dependency ecosystem is captured:\n\n#### Recursive Dependency Deep Dive\n```\nFOR EACH operation IN dependencies:\n  1. Check operation in Candidate Dependencies table\n  2. IF operation has required IDs:\n     - Find creator operations for those IDs\n     - IF creators NOT in dependencies: ADD them\n     - REPEAT this process for newly added creators\n  3. Continue until NO MORE missing dependencies found\n```\n\n#### Complete Execution Path Verification\n```\nVERIFICATION CHECKLIST:\n□ Target operation can execute (all its required IDs have creators)\n□ Each dependency can execute (all their required IDs have creators)  \n□ Authentication context exists for ALL operations requiring authorization\n□ No operation depends on resources that aren\'t created earlier in the chain\n□ Execution sequence is valid from start to finish\n```\n\n#### Dependency Chain Completeness Test\nBefore setting `pass: true`, ask yourself:\n- "If I execute these dependencies in order, will EVERY operation have all its required resources available?"\n- "Are there any missing links in the chain from authentication to target execution?"\n- "Have I checked EVERY creator operation for its own dependencies recursively?"\n\n### Completeness Failure Examples\n```\nINCOMPLETE SCENARIO (pass: false):\nDependencies: [POST /auth/user/join, POST /articles]\nTarget: POST /articles/{articleId}/comments\nIssue: Missing commentId creator\n\nINCOMPLETE SCENARIO (pass: false):  \nDependencies: [POST /auth/user/join, POST /categories, POST /articles]\nBut POST /articles requires userId and Candidate Dependencies shows it needs userId\nIssue: POST /articles can\'t execute because userId dependency missing\n\nCOMPLETE SCENARIO (pass: true):\nDependencies: [POST /auth/user/join, POST /categories, POST /articles, POST /articles/{articleId}/comments]\nAll operations can execute in sequence with required resources available\n```\n\n## DUPLICATE REMOVAL ALGORITHM\n\n```\nDEDUPLICATION RULES:\n1. Group operations by: operation.method + operation.path\n2. If duplicates found:\n   - Keep FIRST occurrence\n   - Remove all subsequent duplicates\n3. Special case - Authentication operations:\n   - Keep only ONE authentication operation per required role\n   - Must only use join for new user scenarios\n```\n\n## AUTHENTICATION CONTEXT VALIDATION\n\n### Authentication Requirements Analysis\n```\nFOR EACH operation IN dependencies + target_operation:\n  IF operation.authorizationRole IS NOT null:\n    required_auth_role = operation.authorizationRole\n    auth_operation = find_auth_operation_for_role(required_auth_role)\n    IF auth_operation NOT IN dependencies:\n      ADD auth_operation TO dependencies (at beginning)\n    END IF\n  END IF\nEND FOR\n```\n\n### Authentication Type Selection\n- **join operations**: Create new user accounts (POST /auth/{role}/join)\n- **login operations**: Use existing accounts (POST /auth/{role}/login)\n- **Default choice**: Use join for test scenarios (creates isolated test data)\n\n## EXECUTION ORDER ALGORITHM\n\nSort dependencies using this strict ordering:\n\n```\nORDER PRIORITY:\n1. Authentication operations (authorizationType: "join" or "login") → FIRST\n2. Independent entities (no required IDs in Candidate Dependencies)\n3. Level 1 dependencies (depend only on independent entities)\n4. Level 2 dependencies (depend on Level 1 entities)\n5. Continue by dependency level until target operation\n6. Target operation → LAST (not in dependencies, but validates ordering)\n```\n\n### Dependency Level Calculation\n```\nFOR EACH operation:\n  IF operation has no required IDs:\n    level = 0 (independent)\n  ELSE:\n    level = max(dependency_levels) + 1\n  END IF\n```\n\n## DETAILED ANALYSIS PROCESS\n\nFor each scenario, output your analysis process:\n\n### Analysis Format\n```\nSCENARIO ANALYSIS: {scenario.functionName}\nRequired IDs: [{list from requiredIds field}]\n\nID MAPPING ANALYSIS:\n- articleId → Found: POST /articles → Status: [Present/Missing] in dependencies\n- categoryId → Found: POST /categories → Status: [Present/Missing] in dependencies\n- userId → Found: POST /auth/user/join → Status: [Present/Missing] in dependencies\n\nAUTHENTICATION ANALYSIS:\n- Target operation authorization: {authorizationRole}\n- Required authentication: {auth operation needed}\n- Current authentication: {auth operations in dependencies}\n\nDUPLICATE ANALYSIS:\n- Found duplicates: [{list of duplicate operations}]\n- Actions: [{list of removals}]\n\nRECURSIVE DEPENDENCY ANALYSIS:\n- Checking POST /articles dependencies: {required IDs from Candidate Dependencies}\n- Missing recursive dependencies: [{list}]\n- Added: [{operations added to complete the chain}]\n\nEXECUTION ORDER ANALYSIS:\n- Current order: [{current dependency order}]\n- Corrected order: [{logical execution order}]\n\nCOMPLETENESS VERIFICATION:\n- Can all operations execute in sequence? [Yes/No]\n- Any missing links in execution chain? [Yes/No]\n- All required resources available when needed? [Yes/No]\n```\n\n## OUTPUT DECISION FRAMEWORK\n\n### Option A: Pass Without Changes (`pass: true`)\n**Use ONLY when ALL conditions are met:**\n- [ ] Every ID in `requiredIds` has a corresponding creator operation in dependencies\n- [ ] All recursive dependencies are included (check each creator operation in Candidate Dependencies)\n- [ ] All authentication requirements are satisfied\n- [ ] No duplicate operations exist\n- [ ] Dependencies are ordered correctly for execution\n- [ ] All referenced operations exist in Available API Operations\n- [ ] **COMPLETENESS VERIFICATION**: Confirm that ALL necessary dependencies have been identified by checking:\n  - Each creator operation\'s own dependencies (recursive check using Candidate Dependencies table)\n  - All authorization requirements throughout the entire dependency chain\n  - No missing links in the complete execution path from authentication to target operation\n\n### Option B: Provide Corrections (`pass: false`)\n**Use when ANY condition fails and provide corrected dependencies**\n\n## VALIDATION EXAMPLES\n\n### Example 1: Complete ID Coverage\n```\nScenario Target: PUT /articles/{articleId}/comments/{commentId}\nRequired IDs: ["articleId", "commentId", "userId"]\n\nExpected Dependencies (Correct Order):\n1. POST /auth/user/join (creates userId, establishes user context)\n2. POST /articles (creates articleId, may need userId)\n3. POST /articles/{articleId}/comments (creates commentId, needs articleId)\n\nAnalysis:\n- articleId → POST /articles ✓\n- commentId → POST /articles/{articleId}/comments ✓  \n- userId → POST /auth/user/join ✓\n```\n\n### Example 2: Missing Creator Operations\n```\nScenario Target: POST /orders\nRequired IDs: ["productId", "userId", "shippingAddressId"]\nCurrent Dependencies: [POST /auth/user/join]\n\nMissing Creators:\n- productId → ADD: POST /products\n- shippingAddressId → ADD: POST /users/{userId}/addresses\n\nCorrected Dependencies:\n1. POST /auth/user/join (creates userId)\n2. POST /products (creates productId)  \n3. POST /users/{userId}/addresses (creates shippingAddressId, needs userId)\n```\n\n### Example 3: Recursive Dependency Analysis\n```\nScenario Target: POST /articles/{articleId}/comments\nRequired IDs: ["articleId"]\nCurrent Dependencies: [POST /articles]\n\nRecursive Check:\n- POST /articles checked in Candidate Dependencies\n- POST /articles requires: ["categoryId", "userId"]\n- Missing: POST /categories, POST /auth/user/join\n\nCorrected Dependencies:\n1. POST /auth/user/join (creates userId)\n2. POST /categories (creates categoryId)\n3. POST /articles (creates articleId, needs userId + categoryId)\n```\n\n### Example 4: Duplicate Removal\n```\nCurrent Dependencies:\n1. POST /auth/user/join (purpose: "Create user")\n2. POST /categories (purpose: "Create category")\n3. POST /auth/user/join (purpose: "Establish authentication")\n\nIssue: Duplicate authentication operation\nSolution: Remove second occurrence, keep first\n```\n\n## ERROR HANDLING GUIDELINES\n\n### When Creator Operation Not Found\n```\nIF required_id has no creator operation in Available API Operations:\n  1. Mark as external/pre-existing resource\n  2. Document in analysis output\n  3. Do NOT add non-existent operations to dependencies\n  4. Continue validation for other IDs\n```\n\n### When Multiple Creator Candidates Exist\n```\nIF multiple operations could create the same resource:\n  1. Prefer POST operations over other methods\n  2. Prefer direct resource creation over nested creation\n  3. Choose the most specific creator (POST /articles over POST /content)\n```\n\n## SUCCESS CRITERIA\n\nA successful review ensures:\n- **Complete ID Coverage**: Every requiredIds entry has a creator in dependencies\n- **Complete Recursive Coverage**: All creator operations\' dependencies are also included\n- **No Duplicates**: Clean, non-redundant dependency list\n- **Proper Authentication**: User context correctly established\n- **Logical Ordering**: Dependencies follow execution sequence\n- **Valid Operations**: All references exist in Available API Operations\n- **Implementable Scenarios**: Complete test execution path from setup to target\n- **End-to-End Verification**: Entire dependency chain can execute successfully\n\n## CRITICAL REMINDERS\n\n1. **Required IDs Are MANDATORY**: Every ID in `requiredIds` MUST have a creator operation\n2. **Recursive Analysis Is CRITICAL**: Check EVERY creator operation for its own dependencies\n3. **Completeness Before Pass**: Only pass when the ENTIRE dependency ecosystem is complete\n4. **Systematic Search**: Use ID mapping rules consistently\n5. **Duplicate Elimination**: Remove redundant operations automatically\n6. **Authentication First**: Always place auth operations at the beginning\n7. **Verify Existence**: Only reference operations from Available API Operations list\n8. **Logical Ordering**: Ensure dependencies can execute in sequence\n9. **Analysis Documentation**: Show your work for transparency\n10. **Final Verification**: Ask yourself if the entire execution path is bulletproof\n\nYour thorough analysis ensures test scenarios are fully implementable and will execute successfully with complete dependency coverage.'
+    }, {
+        id: v7(),
+        created_at: (new Date).toISOString(),
+        type: "assistantMessage",
+        text: StringUtil.trim`
+        # Available API Operations for Reference
+
+        Below are all available API operations and interface schemas for validation purposes.
+        Match each operation with its corresponding schema.
+
+        \`\`\`json
+        ${JSON.stringify({
+            operations: document.operations
+        })}
+        \`\`\`
+      `
+    }, {
+        id: v7(),
+        created_at: (new Date).toISOString(),
+        type: "assistantMessage",
+        text: StringUtil.trim`
+
+      # Test Scenario Groups
+
+      Please review the following test scenario groups:
+
+      \`\`\`json
+      ${JSON.stringify(groups.map(g => ({
+            ...g,
+            scenarios: g.scenarios.map(s => {
+                const requiredId = [];
+                s.dependencies.forEach(dep => {
+                    document.operations.forEach(op => {
+                        if (g.endpoint.method === op.method && g.endpoint.path === op.path) {
+                            requiredId.push(...getReferenceIds({
+                                document,
+                                operation: op
+                            }));
+                        }
+                        if (op.method === dep.endpoint.method && op.path === dep.endpoint.path) {
+                            requiredId.push(...getReferenceIds({
+                                document,
+                                operation: op
+                            }));
+                        }
+                    });
+                });
+                return {
+                    ...s,
+                    requiredIds: requiredId.length > 0 ? Array.from(new Set(requiredId)) : []
+                };
+            })
+        })))}
+      \`\`\`
+      `
+    }, {
+        id: v7(),
+        created_at: (new Date).toISOString(),
+        type: "assistantMessage",
+        text: StringUtil.trim`
+        # Candidate Dependencies
+    
+        List of candidate dependencies extracted from path parameters and request bodies.
+
+        Apply dependency resolution to the target endpoint from "Included in Test Plan" and to dependencies found recursively from it.
+        For each required ID, locate the operation that creates the resource. Include the creator only if that operation exists in the provided operations list. Do not assume or invent operations. If no creator exists, treat the ID as an external or pre-existing input.
+
+        Dependency resolution steps:
+        1. Starting from the target endpoint, collect required IDs.
+        2. For each ID, search for a creator operation (typically POST).
+        3. If found, add it to the dependency chain in execution order and repeat for its own required IDs.
+        4. Stop when no further creators exist or are needed.
+
+        For each some_entity_id pattern, use the same approach: include a creator only when it is present in the operations list.
+    
+        Endpoint | Required IDs (MUST be created by other APIs)
+        ---------|---------------------------------------------------
+        ${relationships.map(r => [ `\`${r.endpoint.method} ${r.endpoint.path}\``, r.ids.map(id => `\`${id}\``).join(", ") ].join(" | ")).join("\n")}
+
+        Example: If an endpoint requires \`articleId\` and \`POST /articles\` exists, include it in dependencies
+      `
+    } ];
+}
+
+async function orchestrateTestScenarioReview(ctx, groups, progress) {
+    const res = await review(ctx, groups, progress);
+    return res;
+}
+
+async function review(ctx, groups, progress) {
+    try {
+        const pointer = {
+            value: null
+        };
+        const {tokenUsage} = await ctx.conversate({
+            source: "testScenariosReview",
+            controller: createController$2({
+                model: ctx.model,
+                pointer,
+                originalGroups: groups
+            }),
+            histories: transformTestScenarioReviewHistories(ctx, groups),
+            enforceFunctionCall: true,
+            message: "Review the Test Scenario."
+        });
+        if (pointer.value === null) {
+            throw new Error("Failed to get review result.");
+        }
+        progress.total = Math.max(progress.total, progress.completed += pointer.value.scenarioGroups.length);
+        ctx.dispatch({
+            type: "testScenariosReview",
+            id: v7(),
+            tokenUsage,
+            total: progress.total,
+            completed: progress.completed,
+            scenarios: pointer.value.scenarioGroups.map(group => group.scenarios.map(s => ({
+                ...s,
+                endpoint: group.endpoint
+            }))).flat(),
+            step: ctx.state().interface?.step ?? 0,
+            created_at: (new Date).toISOString()
+        });
+        return pointer.value.scenarioGroups;
+    } catch {
+        progress.completed += groups.length;
+        return groups;
+    }
+}
+
+function createController$2(props) {
+    assertSchemaModel(props.model);
+    const validate = next => {
+        const result = (() => {
+            const _io0 = input => "string" === typeof input.review && "string" === typeof input.plan && "boolean" === typeof input.pass && (Array.isArray(input.scenarioGroups) && input.scenarioGroups.every(elem => "object" === typeof elem && null !== elem && _io1(elem)));
+            const _io1 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && (Array.isArray(input.scenarios) && (1 <= input.scenarios.length && input.scenarios.every(elem => "object" === typeof elem && null !== elem && _io3(elem))));
+            const _io2 = input => "string" === typeof input.path && RegExp("^\\/[a-zA-Z0-9\\/_{}.-]*$").test(input.path) && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method);
+            const _io3 = input => "string" === typeof input.draft && "string" === typeof input.functionName && (Array.isArray(input.dependencies) && input.dependencies.every(elem => "object" === typeof elem && null !== elem && _io4(elem)));
+            const _io4 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && "string" === typeof input.purpose;
+            const _vo0 = (input, _path, _exceptionable = true) => [ "string" === typeof input.review || _report(_exceptionable, {
+                path: _path + ".review",
+                expected: "string",
+                value: input.review
+            }), "string" === typeof input.plan || _report(_exceptionable, {
+                path: _path + ".plan",
+                expected: "string",
+                value: input.plan
+            }), "boolean" === typeof input.pass || _report(_exceptionable, {
+                path: _path + ".pass",
+                expected: "boolean",
+                value: input.pass
+            }), (Array.isArray(input.scenarioGroups) || _report(_exceptionable, {
+                path: _path + ".scenarioGroups",
+                expected: "Array<IAutoBeTestScenarioApplication.IScenarioGroup>",
+                value: input.scenarioGroups
+            })) && input.scenarioGroups.map((elem, _index4) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                path: _path + ".scenarioGroups[" + _index4 + "]",
+                expected: "IAutoBeTestScenarioApplication.IScenarioGroup",
+                value: elem
+            })) && _vo1(elem, _path + ".scenarioGroups[" + _index4 + "]", _exceptionable) || _report(_exceptionable, {
+                path: _path + ".scenarioGroups[" + _index4 + "]",
+                expected: "IAutoBeTestScenarioApplication.IScenarioGroup",
+                value: elem
+            })).every(flag => flag) || _report(_exceptionable, {
+                path: _path + ".scenarioGroups",
+                expected: "Array<IAutoBeTestScenarioApplication.IScenarioGroup>",
+                value: input.scenarioGroups
+            }) ].every(flag => flag);
+            const _vo1 = (input, _path, _exceptionable = true) => [ ("object" === typeof input.endpoint && null !== input.endpoint || _report(_exceptionable, {
+                path: _path + ".endpoint",
+                expected: "AutoBeOpenApi.IEndpoint",
+                value: input.endpoint
+            })) && _vo2(input.endpoint, _path + ".endpoint", _exceptionable) || _report(_exceptionable, {
+                path: _path + ".endpoint",
+                expected: "AutoBeOpenApi.IEndpoint",
+                value: input.endpoint
+            }), (Array.isArray(input.scenarios) || _report(_exceptionable, {
+                path: _path + ".scenarios",
+                expected: "(Array<IAutoBeTestScenarioApplication.IScenario> & MinItems<1>)",
+                value: input.scenarios
+            })) && ((1 <= input.scenarios.length || _report(_exceptionable, {
+                path: _path + ".scenarios",
+                expected: "Array<> & MinItems<1>",
+                value: input.scenarios
+            })) && input.scenarios.map((elem, _index5) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                path: _path + ".scenarios[" + _index5 + "]",
+                expected: "IAutoBeTestScenarioApplication.IScenario",
+                value: elem
+            })) && _vo3(elem, _path + ".scenarios[" + _index5 + "]", _exceptionable) || _report(_exceptionable, {
+                path: _path + ".scenarios[" + _index5 + "]",
+                expected: "IAutoBeTestScenarioApplication.IScenario",
+                value: elem
+            })).every(flag => flag)) || _report(_exceptionable, {
+                path: _path + ".scenarios",
+                expected: "(Array<IAutoBeTestScenarioApplication.IScenario> & MinItems<1>)",
+                value: input.scenarios
+            }) ].every(flag => flag);
+            const _vo2 = (input, _path, _exceptionable = true) => [ "string" === typeof input.path && (RegExp("^\\/[a-zA-Z0-9\\/_{}.-]*$").test(input.path) || _report(_exceptionable, {
+                path: _path + ".path",
+                expected: 'string & Pattern<"^\\\\/[a-zA-Z0-9\\\\/_{}.-]*$">',
+                value: input.path
+            })) || _report(_exceptionable, {
+                path: _path + ".path",
+                expected: '(string & Pattern<"^\\\\/[a-zA-Z0-9\\\\/_{}.-]*$">)',
+                value: input.path
+            }), "get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method || _report(_exceptionable, {
+                path: _path + ".method",
+                expected: '("delete" | "get" | "patch" | "post" | "put")',
+                value: input.method
+            }) ].every(flag => flag);
+            const _vo3 = (input, _path, _exceptionable = true) => [ "string" === typeof input.draft || _report(_exceptionable, {
+                path: _path + ".draft",
+                expected: "string",
+                value: input.draft
+            }), "string" === typeof input.functionName || _report(_exceptionable, {
+                path: _path + ".functionName",
+                expected: "string",
+                value: input.functionName
+            }), (Array.isArray(input.dependencies) || _report(_exceptionable, {
+                path: _path + ".dependencies",
+                expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
+                value: input.dependencies
+            })) && input.dependencies.map((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                path: _path + ".dependencies[" + _index6 + "]",
+                expected: "IAutoBeTestScenarioApplication.IDependencies",
+                value: elem
+            })) && _vo4(elem, _path + ".dependencies[" + _index6 + "]", _exceptionable) || _report(_exceptionable, {
+                path: _path + ".dependencies[" + _index6 + "]",
+                expected: "IAutoBeTestScenarioApplication.IDependencies",
+                value: elem
+            })).every(flag => flag) || _report(_exceptionable, {
+                path: _path + ".dependencies",
+                expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
+                value: input.dependencies
+            }) ].every(flag => flag);
+            const _vo4 = (input, _path, _exceptionable = true) => [ ("object" === typeof input.endpoint && null !== input.endpoint || _report(_exceptionable, {
+                path: _path + ".endpoint",
+                expected: "AutoBeOpenApi.IEndpoint",
+                value: input.endpoint
+            })) && _vo2(input.endpoint, _path + ".endpoint", _exceptionable) || _report(_exceptionable, {
+                path: _path + ".endpoint",
+                expected: "AutoBeOpenApi.IEndpoint",
+                value: input.endpoint
+            }), "string" === typeof input.purpose || _report(_exceptionable, {
+                path: _path + ".purpose",
+                expected: "string",
+                value: input.purpose
+            }) ].every(flag => flag);
+            const __is = input => "object" === typeof input && null !== input && _io0(input);
+            let errors;
+            let _report;
+            return input => {
+                if (false === __is(input)) {
+                    errors = [];
+                    _report = __typia_transform__validateReport._validateReport(errors);
+                    ((input, _path, _exceptionable = true) => ("object" === typeof input && null !== input || _report(true, {
+                        path: _path + "",
+                        expected: "IAutoBeTestScenarioReviewApplication.IProps",
+                        value: input
+                    })) && _vo0(input, _path + "", true) || _report(true, {
+                        path: _path + "",
+                        expected: "IAutoBeTestScenarioReviewApplication.IProps",
+                        value: input
+                    }))(input, "$input", true);
+                    const success = 0 === errors.length;
+                    return success ? {
+                        success,
+                        data: input
+                    } : {
+                        success,
+                        errors,
+                        data: input
+                    };
+                }
+                return {
+                    success: true,
+                    data: input
+                };
+            };
+        })()(next);
+        if (result.success === false) return result;
+        const scenarioGroups = uniqueScenarioGroups$1(result.data.scenarioGroups);
+        const errors = [];
+        const filteredScenarioGroups = props.originalGroups.reduce((acc, originalGroup) => {
+            const matchingGroup = scenarioGroups.find(g => g.endpoint.method === originalGroup.endpoint.method && g.endpoint.path === originalGroup.endpoint.path);
+            if (!matchingGroup) {
+                return [ ...acc, originalGroup ];
+            }
+            return [ ...acc, matchingGroup ];
+        }, []);
+        result.data.scenarioGroups = filteredScenarioGroups;
+        if (errors.length > 0) {
+            return {
+                success: false,
+                errors,
+                data: result.data
+            };
+        }
+        return result;
+    };
+    const application = collection$3[props.model === "chatgpt" ? "chatgpt" : "claude"](validate);
+    return {
+        protocol: "class",
+        name: "Test Scenario Reviewer",
+        application,
+        execute: {
+            review: input => {
+                props.pointer.value = input;
+            }
+        }
+    };
+}
+
+const uniqueScenarioGroups$1 = groups => new HashMap(groups.map(g => new Pair(g.endpoint, g)), AutoBeEndpointComparator.hashCode, AutoBeEndpointComparator.equals).toJSON().map(it => it.second);
+
+const collection$3 = {
+    chatgpt: validate => (() => {
+        const application = {
+            model: "chatgpt",
+            options: {
+                reference: true,
+                strict: false,
+                separate: null
+            },
+            functions: [ {
+                name: "review",
+                parameters: {
+                    description: "Current Type: {@link IAutoBeTestScenarioReviewApplication.IProps}",
+                    type: "object",
+                    properties: {
+                        review: {
+                            description: "Concise review summary focusing on critical findings and key\nimprovements.\n\nShould include:\n\n- Executive summary of overall quality\n- Critical issues requiring immediate fixes\n- Key improvement recommendations\n- Database schema compliance status\n- Modified scenarios identification by functionName",
+                            type: "string"
+                        },
+                        plan: {
+                            description: "Structured action plan with priority-based improvements.\n\nShould contain:\n\n- Critical fixes required immediately\n- High priority enhancements\n- Implementation guidance\n- Success criteria\n- Specific scenario action items by functionName",
+                            type: "string"
+                        },
+                        pass: {
+                            description: "If the scenario groups pass the review, Set to true.",
+                            type: "boolean"
+                        },
+                        scenarioGroups: {
+                            description: "The reviewed and improved scenario groups with all quality fixes applied.\n\nThis is the primary output containing:\n\n- All critical issues resolved\n- Authentication flows corrected\n- Database dependencies validated\n- Quality enhancements implemented\n- Only implementable scenarios retained",
+                            type: "array",
+                            items: {
+                                $ref: "#/$defs/IAutoBeTestScenarioApplication.IScenarioGroup"
+                            }
+                        }
+                    },
+                    required: [ "review", "plan", "pass", "scenarioGroups" ],
+                    additionalProperties: false,
+                    $defs: {
+                        "IAutoBeTestScenarioApplication.IScenarioGroup": {
+                            description: "### Description of {@link endpoint} property:\n\n> Target API endpoint to test.\n> \n> This must be **unique** across all scenario groups. An endpoint is\n> identified by its `path` and `method` combination.\n> \n> Multiple test scenarios may exist for a single endpoint.",
+                            type: "object",
+                            properties: {
+                                endpoint: {
+                                    $ref: "#/$defs/AutoBeOpenApi.IEndpoint"
+                                },
+                                scenarios: {
+                                    description: "An array of test scenarios associated with the given endpoint.\n\nEach scenario represents a specific test case for the same `path` and\n`method`.\n\nIMPORTANT: Each scenario must be actually implementable. A scenario's\nimplementability is determined by the existence of ALL APIs (endpoints)\nrequired to test it. This includes not only the primary endpoint being\ntested, but also ALL dependency endpoints needed for setup,\nauthentication, and data preparation. If even one required dependency API\nis missing from the available operations, the scenario cannot be\nimplemented and should not be generated.\n\nExample: A \"test banned user login\" scenario requires both a login API\nAND a ban user API. If the ban API doesn't exist, this scenario is not\nimplementable regardless of database schema fields.\n\n\n@minItems 1",
+                                    type: "array",
+                                    items: {
+                                        $ref: "#/$defs/IAutoBeTestScenarioApplication.IScenario"
+                                    }
+                                }
+                            },
+                            required: [ "endpoint", "scenarios" ]
+                        },
+                        "AutoBeOpenApi.IEndpoint": {
+                            description: "API endpoint information.",
+                            type: "object",
+                            properties: {
+                                path: {
+                                    description: 'HTTP path of the API operation.\n\nThe URL path for accessing this API operation, using path parameters\nenclosed in curly braces (e.g., `/shoppings/customers/sales/{saleId}`).\n\nIt must be corresponded to the {@link parameters path parameters}.\n\nThe path structure should clearly indicate which database entity this\noperation is manipulating, helping to ensure all entities have\nappropriate API coverage.\n\nPath validation rules:\n\n- Must start with a forward slash (/)\n- Can contain only: letters (a-z, A-Z), numbers (0-9), forward slashes (/),\n  curly braces for parameters ({paramName}), hyphens (-), and underscores\n  (_)\n- Parameters must be enclosed in curly braces: {paramName}\n- Resource names should be in camelCase\n- No quotes, spaces, or invalid special characters allowed\n- No domain or role-based prefixes\n\nValid examples:\n\n- "/users"\n- "/users/{userId}"\n- "/articles/{articleId}/comments"\n- "/attachmentFiles"\n- "/orders/{orderId}/items/{itemId}"\n\nInvalid examples:\n\n- "\'/users\'" (contains quotes)\n- "/user profile" (contains space)\n- "/users/[userId]" (wrong bracket format)\n- "/admin/users" (role prefix)\n- "/api/v1/users" (API prefix)\n\n\n@pattern ^\\/[a-zA-Z0-9\\/_{}.-]*$',
+                                    type: "string"
+                                },
+                                method: {
+                                    description: 'HTTP method of the API operation.\n\n**IMPORTANT**: Methods must be written in lowercase only (e.g., "get",\nnot "GET").\n\nNote that, if the API operation has {@link requestBody}, method must not\nbe `get`.\n\nAlso, even though the API operation has been designed to only get\ninformation, but it needs complicated request information, it must be\ndefined as `patch` method with {@link requestBody} data specification.\n\n- `get`: get information\n- `patch`: get information with complicated request data\n  ({@link requestBody})\n- `post`: create new record\n- `put`: update existing record\n- `delete`: remove record',
+                                    type: "string",
+                                    enum: [ "get", "post", "put", "delete", "patch" ]
+                                }
+                            },
+                            required: [ "path", "method" ]
+                        },
+                        "IAutoBeTestScenarioApplication.IScenario": {
+                            description: "Represents a test scenario for a single API operation.\n\nThis interface defines a structured, user-centric test draft that includes\na descriptive function name, a detailed scenario draft, and logical\ndependencies on other endpoints required for context or setup.\n\nCRITICAL: All referenced endpoints MUST exist in the provided API\noperations. Do NOT create scenarios for non-existent APIs, even if database\nschema fields suggest their existence. Test scenarios must be implementable\nwith available APIs only.",
+                            type: "object",
+                            properties: {
+                                draft: {
+                                    description: "A detailed natural language description of how this API endpoint should\nbe tested. This should include both successful and failure scenarios,\nbusiness rule validations, edge cases, and any sequence of steps\nnecessary to perform the test. A subsequent agent will use this draft to\ngenerate multiple concrete test cases.",
+                                    type: "string"
+                                },
+                                functionName: {
+                                    description: "Descriptive function name derived from the user scenario.\n\nThe function name serves as a concise, technical identifier that clearly\nrepresents the specific user scenario being described. It should be\nimmediately understandable and directly correspond to the user situation\nwithout requiring additional context.\n\n## Naming Convention\n\nDO: Use snake_case naming convention.\n\n- Must start with `test_api_` prefix (mandatory requirement)\n- ALWAYS start with business feature, NOT action verbs\n- Business feature comes first, followed by scenario context\n- Embed action verbs within the scenario description, not at the beginning\n\n## Content Structure\n\nFunction names should follow this pattern:\n`test_api_[core_feature]_[specific_scenario]`\n\nWhere:\n\n- `core_feature`: The main business feature or entity being tested\n  (customer, seller, cart, push_message, etc.)\n- `specific_scenario`: The specific operation or scenario context\n  (join_verification_not_found, login_success,\n  moderator_assignment_update, discountable_ticket_duplicated,\n  csv_export, etc.)\n\n## Business Feature-Based Examples\n\n- `test_api_customer_join_verification_not_found` - Customer join\n  verification when verification code not found\n- `test_api_seller_login` - Seller login operation\n- `test_api_cart_discountable_ticket_duplicated` - Cart discountable ticket\n  with duplication scenario\n- `test_api_push_message_csv` - Push message functionality with CSV format\n- `test_api_product_review_update` - Product review update operation\n\n## Clarity Guidelines\n\n- Prioritize clarity over brevity\n- Avoid technical jargon or implementation terms\n- Use terminology that reflects user perspective\n- Ensure the name alone conveys the user's intent\n- Make it understandable to non-technical stakeholders\n- Keep consistent with user scenario description\n\n## Single Endpoint Alignment\n\nFunction names must reflect scenarios that:\n\n- Accomplish user goals through this single endpoint only\n- Don't imply dependency on other API operations\n- Represent complete user interactions",
+                                    type: "string"
+                                },
+                                dependencies: {
+                                    description: "A list of other API endpoints that this scenario logically depends on.\n\nThese dependencies represent context or prerequisite conditions, such as\nauthentication, resource creation, or data setup, that are relevant to\nthe test. This list is not a strict execution order — if ordering is\nimportant, it must be described explicitly in the `purpose`.\n\nWARNING: Every endpoint referenced here MUST exist in the provided API\noperations. Do NOT reference endpoints that are not explicitly available,\neven if they seem logically necessary based on database schema or\nbusiness logic.",
+                                    type: "array",
+                                    items: {
+                                        $ref: "#/$defs/IAutoBeTestScenarioApplication.IDependencies"
+                                    }
+                                }
+                            },
+                            required: [ "draft", "functionName", "dependencies" ]
+                        },
+                        "IAutoBeTestScenarioApplication.IDependencies": {
+                            description: "### Description of {@link endpoint} property:\n\n> Target API endpoint that this scenario depends on.\n> \n> This endpoint MUST exist in the available API operations list.\n> Non-existent endpoints will cause test implementation failures.",
+                            type: "object",
+                            properties: {
+                                endpoint: {
+                                    $ref: "#/$defs/AutoBeOpenApi.IEndpoint"
+                                },
+                                purpose: {
+                                    description: 'A concise explanation of why this API call is relevant or required for\nthe main test scenario.\n\nThis should describe the contextual or setup role of the dependency, such\nas creating necessary data or establishing user authentication.\n\nExample: "Creates a category so that a product can be linked to it during\ncreation."',
+                                    type: "string"
+                                }
+                            },
+                            required: [ "endpoint", "purpose" ]
+                        }
+                    }
+                },
+                validate: (() => {
+                    const _io0 = input => "string" === typeof input.review && "string" === typeof input.plan && "boolean" === typeof input.pass && (Array.isArray(input.scenarioGroups) && input.scenarioGroups.every(elem => "object" === typeof elem && null !== elem && _io1(elem)));
+                    const _io1 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && (Array.isArray(input.scenarios) && (1 <= input.scenarios.length && input.scenarios.every(elem => "object" === typeof elem && null !== elem && _io3(elem))));
+                    const _io2 = input => "string" === typeof input.path && RegExp("^\\/[a-zA-Z0-9\\/_{}.-]*$").test(input.path) && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method);
+                    const _io3 = input => "string" === typeof input.draft && "string" === typeof input.functionName && (Array.isArray(input.dependencies) && input.dependencies.every(elem => "object" === typeof elem && null !== elem && _io4(elem)));
+                    const _io4 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && "string" === typeof input.purpose;
+                    const _vo0 = (input, _path, _exceptionable = true) => [ "string" === typeof input.review || _report(_exceptionable, {
+                        path: _path + ".review",
+                        expected: "string",
+                        value: input.review
+                    }), "string" === typeof input.plan || _report(_exceptionable, {
+                        path: _path + ".plan",
+                        expected: "string",
+                        value: input.plan
+                    }), "boolean" === typeof input.pass || _report(_exceptionable, {
+                        path: _path + ".pass",
+                        expected: "boolean",
+                        value: input.pass
+                    }), (Array.isArray(input.scenarioGroups) || _report(_exceptionable, {
+                        path: _path + ".scenarioGroups",
+                        expected: "Array<IAutoBeTestScenarioApplication.IScenarioGroup>",
+                        value: input.scenarioGroups
+                    })) && input.scenarioGroups.map((elem, _index4) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                        path: _path + ".scenarioGroups[" + _index4 + "]",
+                        expected: "IAutoBeTestScenarioApplication.IScenarioGroup",
+                        value: elem
+                    })) && _vo1(elem, _path + ".scenarioGroups[" + _index4 + "]", _exceptionable) || _report(_exceptionable, {
+                        path: _path + ".scenarioGroups[" + _index4 + "]",
+                        expected: "IAutoBeTestScenarioApplication.IScenarioGroup",
+                        value: elem
+                    })).every(flag => flag) || _report(_exceptionable, {
+                        path: _path + ".scenarioGroups",
+                        expected: "Array<IAutoBeTestScenarioApplication.IScenarioGroup>",
+                        value: input.scenarioGroups
+                    }) ].every(flag => flag);
+                    const _vo1 = (input, _path, _exceptionable = true) => [ ("object" === typeof input.endpoint && null !== input.endpoint || _report(_exceptionable, {
+                        path: _path + ".endpoint",
+                        expected: "AutoBeOpenApi.IEndpoint",
+                        value: input.endpoint
+                    })) && _vo2(input.endpoint, _path + ".endpoint", _exceptionable) || _report(_exceptionable, {
+                        path: _path + ".endpoint",
+                        expected: "AutoBeOpenApi.IEndpoint",
+                        value: input.endpoint
+                    }), (Array.isArray(input.scenarios) || _report(_exceptionable, {
+                        path: _path + ".scenarios",
+                        expected: "(Array<IAutoBeTestScenarioApplication.IScenario> & MinItems<1>)",
+                        value: input.scenarios
+                    })) && ((1 <= input.scenarios.length || _report(_exceptionable, {
+                        path: _path + ".scenarios",
+                        expected: "Array<> & MinItems<1>",
+                        value: input.scenarios
+                    })) && input.scenarios.map((elem, _index5) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                        path: _path + ".scenarios[" + _index5 + "]",
+                        expected: "IAutoBeTestScenarioApplication.IScenario",
+                        value: elem
+                    })) && _vo3(elem, _path + ".scenarios[" + _index5 + "]", _exceptionable) || _report(_exceptionable, {
+                        path: _path + ".scenarios[" + _index5 + "]",
+                        expected: "IAutoBeTestScenarioApplication.IScenario",
+                        value: elem
+                    })).every(flag => flag)) || _report(_exceptionable, {
+                        path: _path + ".scenarios",
+                        expected: "(Array<IAutoBeTestScenarioApplication.IScenario> & MinItems<1>)",
+                        value: input.scenarios
+                    }) ].every(flag => flag);
+                    const _vo2 = (input, _path, _exceptionable = true) => [ "string" === typeof input.path && (RegExp("^\\/[a-zA-Z0-9\\/_{}.-]*$").test(input.path) || _report(_exceptionable, {
+                        path: _path + ".path",
+                        expected: 'string & Pattern<"^\\\\/[a-zA-Z0-9\\\\/_{}.-]*$">',
+                        value: input.path
+                    })) || _report(_exceptionable, {
+                        path: _path + ".path",
+                        expected: '(string & Pattern<"^\\\\/[a-zA-Z0-9\\\\/_{}.-]*$">)',
+                        value: input.path
+                    }), "get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method || _report(_exceptionable, {
+                        path: _path + ".method",
+                        expected: '("delete" | "get" | "patch" | "post" | "put")',
+                        value: input.method
+                    }) ].every(flag => flag);
+                    const _vo3 = (input, _path, _exceptionable = true) => [ "string" === typeof input.draft || _report(_exceptionable, {
+                        path: _path + ".draft",
+                        expected: "string",
+                        value: input.draft
+                    }), "string" === typeof input.functionName || _report(_exceptionable, {
+                        path: _path + ".functionName",
+                        expected: "string",
+                        value: input.functionName
+                    }), (Array.isArray(input.dependencies) || _report(_exceptionable, {
+                        path: _path + ".dependencies",
+                        expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
+                        value: input.dependencies
+                    })) && input.dependencies.map((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                        path: _path + ".dependencies[" + _index6 + "]",
+                        expected: "IAutoBeTestScenarioApplication.IDependencies",
+                        value: elem
+                    })) && _vo4(elem, _path + ".dependencies[" + _index6 + "]", _exceptionable) || _report(_exceptionable, {
+                        path: _path + ".dependencies[" + _index6 + "]",
+                        expected: "IAutoBeTestScenarioApplication.IDependencies",
+                        value: elem
+                    })).every(flag => flag) || _report(_exceptionable, {
+                        path: _path + ".dependencies",
+                        expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
+                        value: input.dependencies
+                    }) ].every(flag => flag);
+                    const _vo4 = (input, _path, _exceptionable = true) => [ ("object" === typeof input.endpoint && null !== input.endpoint || _report(_exceptionable, {
+                        path: _path + ".endpoint",
+                        expected: "AutoBeOpenApi.IEndpoint",
+                        value: input.endpoint
+                    })) && _vo2(input.endpoint, _path + ".endpoint", _exceptionable) || _report(_exceptionable, {
+                        path: _path + ".endpoint",
+                        expected: "AutoBeOpenApi.IEndpoint",
+                        value: input.endpoint
+                    }), "string" === typeof input.purpose || _report(_exceptionable, {
+                        path: _path + ".purpose",
+                        expected: "string",
+                        value: input.purpose
+                    }) ].every(flag => flag);
+                    const __is = input => "object" === typeof input && null !== input && _io0(input);
+                    let errors;
+                    let _report;
+                    return input => {
+                        if (false === __is(input)) {
+                            errors = [];
+                            _report = __typia_transform__validateReport._validateReport(errors);
+                            ((input, _path, _exceptionable = true) => ("object" === typeof input && null !== input || _report(true, {
+                                path: _path + "",
+                                expected: "IAutoBeTestScenarioReviewApplication.IProps",
+                                value: input
+                            })) && _vo0(input, _path + "", true) || _report(true, {
+                                path: _path + "",
+                                expected: "IAutoBeTestScenarioReviewApplication.IProps",
+                                value: input
+                            }))(input, "$input", true);
+                            const success = 0 === errors.length;
+                            return success ? {
+                                success,
+                                data: input
+                            } : {
+                                success,
+                                errors,
+                                data: input
+                            };
+                        }
+                        return {
+                            success: true,
+                            data: input
+                        };
+                    };
+                })()
+            } ]
+        };
+        __typia_transform__llmApplicationFinalize._llmApplicationFinalize(application, {
+            ...{
+                validate: {
+                    review: validate
+                }
+            },
+            equals: false
+        });
+        return application;
+    })(),
+    claude: validate => (() => {
+        const application = {
+            model: "claude",
+            options: {
+                reference: true,
+                separate: null
+            },
+            functions: [ {
+                name: "review",
+                parameters: {
+                    description: "Current Type: {@link IAutoBeTestScenarioReviewApplication.IProps}",
+                    type: "object",
+                    properties: {
+                        review: {
+                            description: "Concise review summary focusing on critical findings and key\nimprovements.\n\nShould include:\n\n- Executive summary of overall quality\n- Critical issues requiring immediate fixes\n- Key improvement recommendations\n- Database schema compliance status\n- Modified scenarios identification by functionName",
+                            type: "string"
+                        },
+                        plan: {
+                            description: "Structured action plan with priority-based improvements.\n\nShould contain:\n\n- Critical fixes required immediately\n- High priority enhancements\n- Implementation guidance\n- Success criteria\n- Specific scenario action items by functionName",
+                            type: "string"
+                        },
+                        pass: {
+                            description: "If the scenario groups pass the review, Set to true.",
+                            type: "boolean"
+                        },
+                        scenarioGroups: {
+                            description: "The reviewed and improved scenario groups with all quality fixes applied.\n\nThis is the primary output containing:\n\n- All critical issues resolved\n- Authentication flows corrected\n- Database dependencies validated\n- Quality enhancements implemented\n- Only implementable scenarios retained",
+                            type: "array",
+                            items: {
+                                $ref: "#/$defs/IAutoBeTestScenarioApplication.IScenarioGroup"
+                            }
+                        }
+                    },
+                    required: [ "review", "plan", "pass", "scenarioGroups" ],
+                    additionalProperties: false,
+                    $defs: {
+                        "IAutoBeTestScenarioApplication.IScenarioGroup": {
+                            type: "object",
+                            properties: {
+                                endpoint: {
+                                    description: "Target API endpoint to test.\n\nThis must be **unique** across all scenario groups. An endpoint is\nidentified by its `path` and `method` combination.\n\nMultiple test scenarios may exist for a single endpoint.",
+                                    $ref: "#/$defs/AutoBeOpenApi.IEndpoint"
+                                },
+                                scenarios: {
+                                    description: "An array of test scenarios associated with the given endpoint.\n\nEach scenario represents a specific test case for the same `path` and\n`method`.\n\nIMPORTANT: Each scenario must be actually implementable. A scenario's\nimplementability is determined by the existence of ALL APIs (endpoints)\nrequired to test it. This includes not only the primary endpoint being\ntested, but also ALL dependency endpoints needed for setup,\nauthentication, and data preparation. If even one required dependency API\nis missing from the available operations, the scenario cannot be\nimplemented and should not be generated.\n\nExample: A \"test banned user login\" scenario requires both a login API\nAND a ban user API. If the ban API doesn't exist, this scenario is not\nimplementable regardless of database schema fields.",
+                                    type: "array",
+                                    items: {
+                                        $ref: "#/$defs/IAutoBeTestScenarioApplication.IScenario"
+                                    },
+                                    minItems: 1
+                                }
+                            },
+                            required: [ "endpoint", "scenarios" ]
+                        },
+                        "AutoBeOpenApi.IEndpoint": {
+                            description: "API endpoint information.",
+                            type: "object",
+                            properties: {
+                                path: {
+                                    description: 'HTTP path of the API operation.\n\nThe URL path for accessing this API operation, using path parameters\nenclosed in curly braces (e.g., `/shoppings/customers/sales/{saleId}`).\n\nIt must be corresponded to the {@link parameters path parameters}.\n\nThe path structure should clearly indicate which database entity this\noperation is manipulating, helping to ensure all entities have\nappropriate API coverage.\n\nPath validation rules:\n\n- Must start with a forward slash (/)\n- Can contain only: letters (a-z, A-Z), numbers (0-9), forward slashes (/),\n  curly braces for parameters ({paramName}), hyphens (-), and underscores\n  (_)\n- Parameters must be enclosed in curly braces: {paramName}\n- Resource names should be in camelCase\n- No quotes, spaces, or invalid special characters allowed\n- No domain or role-based prefixes\n\nValid examples:\n\n- "/users"\n- "/users/{userId}"\n- "/articles/{articleId}/comments"\n- "/attachmentFiles"\n- "/orders/{orderId}/items/{itemId}"\n\nInvalid examples:\n\n- "\'/users\'" (contains quotes)\n- "/user profile" (contains space)\n- "/users/[userId]" (wrong bracket format)\n- "/admin/users" (role prefix)\n- "/api/v1/users" (API prefix)',
+                                    type: "string",
+                                    pattern: "^\\/[a-zA-Z0-9\\/_{}.-]*$"
+                                },
+                                method: {
+                                    description: 'HTTP method of the API operation.\n\n**IMPORTANT**: Methods must be written in lowercase only (e.g., "get",\nnot "GET").\n\nNote that, if the API operation has {@link requestBody}, method must not\nbe `get`.\n\nAlso, even though the API operation has been designed to only get\ninformation, but it needs complicated request information, it must be\ndefined as `patch` method with {@link requestBody} data specification.\n\n- `get`: get information\n- `patch`: get information with complicated request data\n  ({@link requestBody})\n- `post`: create new record\n- `put`: update existing record\n- `delete`: remove record',
+                                    oneOf: [ {
+                                        const: "get"
+                                    }, {
+                                        const: "post"
+                                    }, {
+                                        const: "put"
+                                    }, {
+                                        const: "delete"
+                                    }, {
+                                        const: "patch"
+                                    } ]
+                                }
+                            },
+                            required: [ "path", "method" ]
+                        },
+                        "IAutoBeTestScenarioApplication.IScenario": {
+                            description: "Represents a test scenario for a single API operation.\n\nThis interface defines a structured, user-centric test draft that includes\na descriptive function name, a detailed scenario draft, and logical\ndependencies on other endpoints required for context or setup.\n\nCRITICAL: All referenced endpoints MUST exist in the provided API\noperations. Do NOT create scenarios for non-existent APIs, even if database\nschema fields suggest their existence. Test scenarios must be implementable\nwith available APIs only.",
+                            type: "object",
+                            properties: {
+                                draft: {
+                                    description: "A detailed natural language description of how this API endpoint should\nbe tested. This should include both successful and failure scenarios,\nbusiness rule validations, edge cases, and any sequence of steps\nnecessary to perform the test. A subsequent agent will use this draft to\ngenerate multiple concrete test cases.",
+                                    type: "string"
+                                },
+                                functionName: {
+                                    description: "Descriptive function name derived from the user scenario.\n\nThe function name serves as a concise, technical identifier that clearly\nrepresents the specific user scenario being described. It should be\nimmediately understandable and directly correspond to the user situation\nwithout requiring additional context.\n\n## Naming Convention\n\nDO: Use snake_case naming convention.\n\n- Must start with `test_api_` prefix (mandatory requirement)\n- ALWAYS start with business feature, NOT action verbs\n- Business feature comes first, followed by scenario context\n- Embed action verbs within the scenario description, not at the beginning\n\n## Content Structure\n\nFunction names should follow this pattern:\n`test_api_[core_feature]_[specific_scenario]`\n\nWhere:\n\n- `core_feature`: The main business feature or entity being tested\n  (customer, seller, cart, push_message, etc.)\n- `specific_scenario`: The specific operation or scenario context\n  (join_verification_not_found, login_success,\n  moderator_assignment_update, discountable_ticket_duplicated,\n  csv_export, etc.)\n\n## Business Feature-Based Examples\n\n- `test_api_customer_join_verification_not_found` - Customer join\n  verification when verification code not found\n- `test_api_seller_login` - Seller login operation\n- `test_api_cart_discountable_ticket_duplicated` - Cart discountable ticket\n  with duplication scenario\n- `test_api_push_message_csv` - Push message functionality with CSV format\n- `test_api_product_review_update` - Product review update operation\n\n## Clarity Guidelines\n\n- Prioritize clarity over brevity\n- Avoid technical jargon or implementation terms\n- Use terminology that reflects user perspective\n- Ensure the name alone conveys the user's intent\n- Make it understandable to non-technical stakeholders\n- Keep consistent with user scenario description\n\n## Single Endpoint Alignment\n\nFunction names must reflect scenarios that:\n\n- Accomplish user goals through this single endpoint only\n- Don't imply dependency on other API operations\n- Represent complete user interactions",
+                                    type: "string"
+                                },
+                                dependencies: {
+                                    description: "A list of other API endpoints that this scenario logically depends on.\n\nThese dependencies represent context or prerequisite conditions, such as\nauthentication, resource creation, or data setup, that are relevant to\nthe test. This list is not a strict execution order — if ordering is\nimportant, it must be described explicitly in the `purpose`.\n\nWARNING: Every endpoint referenced here MUST exist in the provided API\noperations. Do NOT reference endpoints that are not explicitly available,\neven if they seem logically necessary based on database schema or\nbusiness logic.",
+                                    type: "array",
+                                    items: {
+                                        $ref: "#/$defs/IAutoBeTestScenarioApplication.IDependencies"
+                                    }
+                                }
+                            },
+                            required: [ "draft", "functionName", "dependencies" ]
+                        },
+                        "IAutoBeTestScenarioApplication.IDependencies": {
+                            type: "object",
+                            properties: {
+                                endpoint: {
+                                    description: "Target API endpoint that this scenario depends on.\n\nThis endpoint MUST exist in the available API operations list.\nNon-existent endpoints will cause test implementation failures.",
+                                    $ref: "#/$defs/AutoBeOpenApi.IEndpoint"
+                                },
+                                purpose: {
+                                    description: 'A concise explanation of why this API call is relevant or required for\nthe main test scenario.\n\nThis should describe the contextual or setup role of the dependency, such\nas creating necessary data or establishing user authentication.\n\nExample: "Creates a category so that a product can be linked to it during\ncreation."',
+                                    type: "string"
+                                }
+                            },
+                            required: [ "endpoint", "purpose" ]
+                        }
+                    }
+                },
+                validate: (() => {
+                    const _io0 = input => "string" === typeof input.review && "string" === typeof input.plan && "boolean" === typeof input.pass && (Array.isArray(input.scenarioGroups) && input.scenarioGroups.every(elem => "object" === typeof elem && null !== elem && _io1(elem)));
+                    const _io1 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && (Array.isArray(input.scenarios) && (1 <= input.scenarios.length && input.scenarios.every(elem => "object" === typeof elem && null !== elem && _io3(elem))));
+                    const _io2 = input => "string" === typeof input.path && RegExp("^\\/[a-zA-Z0-9\\/_{}.-]*$").test(input.path) && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method);
+                    const _io3 = input => "string" === typeof input.draft && "string" === typeof input.functionName && (Array.isArray(input.dependencies) && input.dependencies.every(elem => "object" === typeof elem && null !== elem && _io4(elem)));
+                    const _io4 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && "string" === typeof input.purpose;
+                    const _vo0 = (input, _path, _exceptionable = true) => [ "string" === typeof input.review || _report(_exceptionable, {
+                        path: _path + ".review",
+                        expected: "string",
+                        value: input.review
+                    }), "string" === typeof input.plan || _report(_exceptionable, {
+                        path: _path + ".plan",
+                        expected: "string",
+                        value: input.plan
+                    }), "boolean" === typeof input.pass || _report(_exceptionable, {
+                        path: _path + ".pass",
+                        expected: "boolean",
+                        value: input.pass
+                    }), (Array.isArray(input.scenarioGroups) || _report(_exceptionable, {
+                        path: _path + ".scenarioGroups",
+                        expected: "Array<IAutoBeTestScenarioApplication.IScenarioGroup>",
+                        value: input.scenarioGroups
+                    })) && input.scenarioGroups.map((elem, _index4) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                        path: _path + ".scenarioGroups[" + _index4 + "]",
+                        expected: "IAutoBeTestScenarioApplication.IScenarioGroup",
+                        value: elem
+                    })) && _vo1(elem, _path + ".scenarioGroups[" + _index4 + "]", _exceptionable) || _report(_exceptionable, {
+                        path: _path + ".scenarioGroups[" + _index4 + "]",
+                        expected: "IAutoBeTestScenarioApplication.IScenarioGroup",
+                        value: elem
+                    })).every(flag => flag) || _report(_exceptionable, {
+                        path: _path + ".scenarioGroups",
+                        expected: "Array<IAutoBeTestScenarioApplication.IScenarioGroup>",
+                        value: input.scenarioGroups
+                    }) ].every(flag => flag);
+                    const _vo1 = (input, _path, _exceptionable = true) => [ ("object" === typeof input.endpoint && null !== input.endpoint || _report(_exceptionable, {
+                        path: _path + ".endpoint",
+                        expected: "AutoBeOpenApi.IEndpoint",
+                        value: input.endpoint
+                    })) && _vo2(input.endpoint, _path + ".endpoint", _exceptionable) || _report(_exceptionable, {
+                        path: _path + ".endpoint",
+                        expected: "AutoBeOpenApi.IEndpoint",
+                        value: input.endpoint
+                    }), (Array.isArray(input.scenarios) || _report(_exceptionable, {
+                        path: _path + ".scenarios",
+                        expected: "(Array<IAutoBeTestScenarioApplication.IScenario> & MinItems<1>)",
+                        value: input.scenarios
+                    })) && ((1 <= input.scenarios.length || _report(_exceptionable, {
+                        path: _path + ".scenarios",
+                        expected: "Array<> & MinItems<1>",
+                        value: input.scenarios
+                    })) && input.scenarios.map((elem, _index5) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                        path: _path + ".scenarios[" + _index5 + "]",
+                        expected: "IAutoBeTestScenarioApplication.IScenario",
+                        value: elem
+                    })) && _vo3(elem, _path + ".scenarios[" + _index5 + "]", _exceptionable) || _report(_exceptionable, {
+                        path: _path + ".scenarios[" + _index5 + "]",
+                        expected: "IAutoBeTestScenarioApplication.IScenario",
+                        value: elem
+                    })).every(flag => flag)) || _report(_exceptionable, {
+                        path: _path + ".scenarios",
+                        expected: "(Array<IAutoBeTestScenarioApplication.IScenario> & MinItems<1>)",
+                        value: input.scenarios
+                    }) ].every(flag => flag);
+                    const _vo2 = (input, _path, _exceptionable = true) => [ "string" === typeof input.path && (RegExp("^\\/[a-zA-Z0-9\\/_{}.-]*$").test(input.path) || _report(_exceptionable, {
+                        path: _path + ".path",
+                        expected: 'string & Pattern<"^\\\\/[a-zA-Z0-9\\\\/_{}.-]*$">',
+                        value: input.path
+                    })) || _report(_exceptionable, {
+                        path: _path + ".path",
+                        expected: '(string & Pattern<"^\\\\/[a-zA-Z0-9\\\\/_{}.-]*$">)',
+                        value: input.path
+                    }), "get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method || _report(_exceptionable, {
+                        path: _path + ".method",
+                        expected: '("delete" | "get" | "patch" | "post" | "put")',
+                        value: input.method
+                    }) ].every(flag => flag);
+                    const _vo3 = (input, _path, _exceptionable = true) => [ "string" === typeof input.draft || _report(_exceptionable, {
+                        path: _path + ".draft",
+                        expected: "string",
+                        value: input.draft
+                    }), "string" === typeof input.functionName || _report(_exceptionable, {
+                        path: _path + ".functionName",
+                        expected: "string",
+                        value: input.functionName
+                    }), (Array.isArray(input.dependencies) || _report(_exceptionable, {
+                        path: _path + ".dependencies",
+                        expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
+                        value: input.dependencies
+                    })) && input.dependencies.map((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                        path: _path + ".dependencies[" + _index6 + "]",
+                        expected: "IAutoBeTestScenarioApplication.IDependencies",
+                        value: elem
+                    })) && _vo4(elem, _path + ".dependencies[" + _index6 + "]", _exceptionable) || _report(_exceptionable, {
+                        path: _path + ".dependencies[" + _index6 + "]",
+                        expected: "IAutoBeTestScenarioApplication.IDependencies",
+                        value: elem
+                    })).every(flag => flag) || _report(_exceptionable, {
+                        path: _path + ".dependencies",
+                        expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
+                        value: input.dependencies
+                    }) ].every(flag => flag);
+                    const _vo4 = (input, _path, _exceptionable = true) => [ ("object" === typeof input.endpoint && null !== input.endpoint || _report(_exceptionable, {
+                        path: _path + ".endpoint",
+                        expected: "AutoBeOpenApi.IEndpoint",
+                        value: input.endpoint
+                    })) && _vo2(input.endpoint, _path + ".endpoint", _exceptionable) || _report(_exceptionable, {
+                        path: _path + ".endpoint",
+                        expected: "AutoBeOpenApi.IEndpoint",
+                        value: input.endpoint
+                    }), "string" === typeof input.purpose || _report(_exceptionable, {
+                        path: _path + ".purpose",
+                        expected: "string",
+                        value: input.purpose
+                    }) ].every(flag => flag);
+                    const __is = input => "object" === typeof input && null !== input && _io0(input);
+                    let errors;
+                    let _report;
+                    return input => {
+                        if (false === __is(input)) {
+                            errors = [];
+                            _report = __typia_transform__validateReport._validateReport(errors);
+                            ((input, _path, _exceptionable = true) => ("object" === typeof input && null !== input || _report(true, {
+                                path: _path + "",
+                                expected: "IAutoBeTestScenarioReviewApplication.IProps",
+                                value: input
+                            })) && _vo0(input, _path + "", true) || _report(true, {
+                                path: _path + "",
+                                expected: "IAutoBeTestScenarioReviewApplication.IProps",
+                                value: input
+                            }))(input, "$input", true);
+                            const success = 0 === errors.length;
+                            return success ? {
+                                success,
+                                data: input
+                            } : {
+                                success,
+                                errors,
+                                data: input
+                            };
+                        }
+                        return {
+                            success: true,
+                            data: input
+                        };
+                    };
+                })()
+            } ]
+        };
+        __typia_transform__llmApplicationFinalize._llmApplicationFinalize(application, {
+            ...{
+                validate: {
+                    review: validate
+                }
+            },
+            equals: false
+        });
+        return application;
+    })()
+};
+
+async function orchestrateTestScenario(ctx) {
+    const document = ctx.state().interface?.document;
+    if (document === undefined) {
+        throw new Error("Cannot write test scenarios because these are no operations.");
+    }
+    const dict = new HashMap(document.operations.map(op => new Pair({
+        path: op.path,
+        method: op.method
+    }, op)), AutoBeEndpointComparator.hashCode, AutoBeEndpointComparator.equals);
+    const endpointNotFound = [ `You have to select one of the endpoints below`, "", " method | path ", "--------|------", ...document.operations.map(op => `\`${op.method}\` | \`${op.path}\``).join("\n") ].join("\n");
+    const progress = {
+        total: document.operations.length,
+        completed: 0
+    };
+    const reviewProgress = {
         total: document.operations.length,
         completed: 0
     };
@@ -28671,6 +29621,7 @@ async function orchestrateTestScenario(ctx) {
                 include,
                 exclude: exclude.map(x => x.endpoint),
                 progress,
+                reviewProgress,
                 promptCacheKey
             }));
         }));
@@ -28681,6 +29632,7 @@ async function orchestrateTestScenario(ctx) {
             return true;
         });
         progress.total = include.length + exclude.length;
+        reviewProgress.total = include.length + exclude.length;
     } while (include.length > 0 && ++trial < ctx.retry);
     return exclude.flatMap(pg => pg.scenarios.map(plan => ({
         endpoint: pg.endpoint,
@@ -28733,7 +29685,7 @@ const divideAndConquer = async (ctx, props) => {
             step: ctx.state().interface?.step ?? 0,
             created_at: (new Date).toISOString()
         });
-        return pointer.value;
+        return await orchestrateTestScenarioReview(ctx, pointer.value, props.reviewProgress);
     } catch {
         return [];
     }
@@ -31163,7 +32115,7 @@ const getCriticalCompiler = (critical, compiler) => {
         realize: {
             controller: props => lock(() => compiler.realize.controller(props)),
             test: props => lock(() => compiler.realize.test(props)),
-            getTemplate: () => lock(() => compiler.realize.getTemplate())
+            getTemplate: options => lock(() => compiler.realize.getTemplate(options))
         }
     };
 };
@@ -31417,7 +32369,7 @@ const forceRetry = async (task, count) => {
     throw error;
 };
 
-const STAGES = [ "analyze", "interface", "prisma", "realize", "test" ];
+const STAGES = [ "analyze", "prisma", "interface", "test", "realize" ];
 
 const createAutoBeState = histories => {
     const reversed = histories.slice().reverse();
@@ -31794,6 +32746,7 @@ const sleepMap = {
     interfaceComplete: 1e3,
     testStart: 1e3,
     testScenarios: 40,
+    testScenariosReview: 40,
     testWrite: 40,
     testValidate: 100,
     testCorrect: 100,