@autobe/agent 0.14.6 → 0.15.0

package/lib/index.mjs

@@ -16,11 +16,9 @@ import { OpenApiTypeChecker, HttpMigration } from "@samchon/openapi";
 
 import { OpenApiV3_1Emender } from "@samchon/openapi/lib/converters/OpenApiV3_1Emender";
 
-import * as __typia_transform__isUniqueItems from "typia/lib/internal/_isUniqueItems.js";
-
-import fs, { readFile } from "fs/promises";
+import { NamingConvention } from "typia/lib/utils/NamingConvention";
 
-import path from "path";
+import * as __typia_transform__isUniqueItems from "typia/lib/internal/_isUniqueItems.js";
 
 async function getAutoBeGenerated(compiler, state, histories, tokenUsage, options) {
     const ret = {};
@@ -234,7 +232,7 @@ class AutoBeAnalyzeComposerApplication {
 
 function createController$1(props) {
     assertSchemaModel(props.model);
-    const application = collection$f[props.model];
+    const application = collection$g[props.model];
     return {
         protocol: "class",
         name: "Compose",
@@ -248,7 +246,7 @@ function createController$1(props) {
     };
 }
 
-const claude$f = {
+const claude$g = {
     model: "claude",
     options: {
         reference: true,
@@ -461,7 +459,7 @@ const claude$f = {
     } ]
 };
 
-const collection$f = {
+const collection$g = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -674,70 +672,12 @@ const collection$f = {
             })()
         } ]
     },
-    claude: claude$f,
-    llama: claude$f,
-    deepseek: claude$f,
-    3.1: claude$f
+    claude: claude$g,
+    llama: claude$g,
+    deepseek: claude$g,
+    3.1: claude$g
 };
 
-async function randomBackoffRetry(fn, options = {}) {
-    const {maxRetries = 5, baseDelay = 4e3, maxDelay = 6e4, jitter = .8, handleError = isRetryError} = options;
-    let lastError;
-    for (let attempt = 0; attempt < maxRetries; attempt++) {
-        try {
-            return await fn();
-        } catch (err) {
-            lastError = err;
-            if (attempt === maxRetries - 1) throw err;
-            if (!handleError(err)) throw err;
-            const tempDelay = Math.min(baseDelay * 2 ** attempt, maxDelay);
-            const delay = tempDelay * (1 + Math.random() * jitter);
-            await new Promise((res => setTimeout(res, delay)));
-        }
-    }
-    throw lastError;
-}
-
-function randomBackoffStrategy(props) {
-    console.log("randomBackoffStrategy");
-    const {count, error} = props;
-    if (count > 5) {
-        throw error;
-    }
-    if (isRetryError(error) === false) {
-        throw error;
-    }
-    const baseDelay = 4e3;
-    const maxDelay = 6e4;
-    const jitter = .8;
-    const tempDelay = Math.min(baseDelay * 2 ** count, maxDelay);
-    const delay = tempDelay * (1 + Math.random() * jitter);
-    return delay;
-}
-
-function isRetryError(error) {
-    if (error?.code === "insufficient_quota" || error?.error?.type === "insufficient_quota") {
-        return false;
-    }
-    if (typeof error?.status === "number" && error.status >= 500 || error?.error?.type === "server_error") {
-        return true;
-    }
-    if (error?.status === 429) {
-        return true;
-    }
-    const code = error?.code || error?.cause?.code;
-    if ([ "UND_ERR_SOCKET", "UND_ERR_CONNECT_TIMEOUT", "ETIMEDOUT", "ECONNRESET", "EPIPE" ].includes(code)) {
-        return true;
-    }
-    if (error?.message === "terminated" || error?.name === "AbortError") {
-        return true;
-    }
-    if (error?.message?.startsWith(`SyntaxError: Expected ',' or '}' after property value in JSON at position`)) {
-        return true;
-    }
-    return false;
-}
-
 const transformAnalyzeReviewerHistories = input => [ {
     id: v4(),
     created_at: (new Date).toISOString(),
@@ -747,7 +687,7 @@ const transformAnalyzeReviewerHistories = input => [ {
     id: v4(),
     created_at: (new Date).toISOString(),
     type: "systemMessage",
-    text: "# Reviewer Agent Operating Guidelines\n\n## Core Principles\n\n* **Only review the document currently being viewed.**\n* Even if there is a section that implies another document, **ignore it.**\n* Even if the current page is a table of contents, **do not request the creation of any other pages.**\n* If a new document is referenced even though the current document is not a table of contents page that begins with `00`,\n  **instruct the planner to clear all content and rewrite the document.**\n* Other documents will be brought in by other agents, so do **not** request the creation of any files other than the current one.\n* **Each agent must write only the single page assigned to them.**  \n  Requests or attempts to write other pages or documents are strictly prohibited.\n* When references to other documents appear in the current page, do not request creation of those documents. Instead,  \n  **instruct the planner to clear all contents and rewrite the current document.**\n\n## Role of the Reviewer\n\n* The reviewer's role is to **ensure the document contains sufficient information before it is delivered to developers.**\n* Below are all the **links currently referenced in the markdown**. Be sure to refer to them and **ensure the corresponding files are created.**\n* **Do not create files that are not specified in the table of contents.**\n* If the user specifies the **exact number of pages**, that number **must be followed exactly.**\n* Reviewers are limited to reviewing **only their assigned single page** and must not engage with other pages or documents.\n* If an agent requests creation of other pages or documents,  \n  the reviewer must issue a command to **stop such requests and enforce focus on the current page only.**\n\n## Prohibited Actions\n\n* The reviewer must **never write their own content under any circumstances.**\n* Reviewers are **independent beings and must never be instructed.**\n* The reviewer's words must be **commands that must be followed, not recommendations.**\n\n## Instructions for Revisions\n\n* If changes are necessary, **provide detailed instructions.**\n* Give **clear and concise instructions**, and **avoid unnecessary remarks.**\n* If the document is too short or insufficient, compare the number of headings to the text length and  \n  **instruct the analyze agent to expand the content within the current page accordingly.**\n* If hyperlinks point to content not included in the current page,  \n  **instruct the analyze agent to add a new section with the hyperlink’s title under the appropriate heading within the same page.**\n\n## If the Document is Sufficient\n\n* If the current level of analysis is deemed sufficient, **make no further requests.**\n* **Notify that the document is complete.**\n\n---\n\n# Guidelines for Document Volume\n\n* It is recommended to instruct the analyze agent to **write a document longer than 2,000 characters** for sufficient utility. (Do not exceed 6,000 characters)\n* If the document is too short, indicate how many characters it currently has and how many more are needed.\n* However, in the case of the table of contents page, it is free from the volume limit.\n* Rather than simply telling them to increase the text, **compare the number of headings to the text length**,\n  and if they want to double the amount, **instruct them to do so accordingly.**\n* When referencing something from the table of contents, clearly **state the name of the section**.\n\n---\n\n# Q\\&A Guidelines\n\n* If the analyze agent asks a question, **the reviewer must answer on behalf of the user.**\n* **Never ask any questions.**\n* **Only give commands.**\n\n---\n\n# Guidelines for Hyperlinks\n\n* Even if a document is high quality, if it contains **incomplete hyperlinks**, it is considered **incomplete**.\n* If a hyperlink points to **content that has not yet been written**, the document is **incomplete regardless of its quality**.\n* However, **incomplete hyperlinks to external documents (outside the current page)** are **allowed**.\n  In such cases, assume that other agents will write those documents and move on without strict enforcement.\n* If a hyperlink points to a **heading within the same document** (i.e., an anchor/fragment link):\n\n  * That heading **must exist** in the document.\n  * If it does not exist, instruct the **analyze agent** to **create a new section with the same title as the hyperlink** and\n    **insert it under the appropriate heading**.\n* If a hyperlink points to an **external document**, and the current document is **not a table of contents page starting with `00`**,\n  the rule above still applies—**incomplete external links are allowed** and do **not** require clearing or rewriting the document.\n\n---\n\n# Review Completion Conditions\n\n* When the document is determined to be complete, clearly give the following instruction:\n  **The analyze agent has a tool called 'abort,' so instruct them to call it to stop the review.**\n* This instruction must only be given **when all the following conditions are met**:\n\n  * All sections listed in the table of contents are **fully written**.\n  * All referenced hyperlinks are **resolved**.\n* If there are still sections to write or links unresolved,\n  instruct the analyze agent to continue writing,\n  including the **specific section title** and a **brief explanation** of what content is needed.\n\n---\n\n# Additional Requirements for Page-Based Work Division\n\n* Each agent must write and review **only their assigned single page** out of the total pages specified.\n* Under no circumstances should an agent request or attempt to create documents beyond their assigned page.\n* If an agent attempts to request content outside their page, immediately command them to **focus solely on the current page.**\n* All document length and content sufficiency checks and corrections must be done within the single assigned page.\n* If multiple pages exist, the total number of pages must be strictly adhered to, and no extra pages should be created.\n* This strict page-level division must be enforced to maintain clear boundaries of responsibility and simplify review workflows.\n\n---\n\n**All these guidelines must be strictly enforced during the document creation and review process. Any violations require immediate correction or rewriting commands.**"
+    text: "# Reviewer Agent Operating Guidelines\n\n## Core Principles\n\n* **Only review the document currently being viewed.**\n* Even if there is a section that implies another document, **ignore it.**\n* Even if the current page is a table of contents, **do not request the creation of any other pages.**\n* If a new document is referenced even though the current document is not a table of contents page that begins with `00`,\n  **instruct the planner to clear all content and rewrite the document.**\n* Other documents will be brought in by other agents, so do **not** request the creation of any files other than the current one.\n* **Each agent must write only the single page assigned to them.**  \n  Requests or attempts to write other pages or documents are strictly prohibited.\n* When references to other documents appear in the current page, do not request creation of those documents. Instead,  \n  **instruct the planner to clear all contents and rewrite the current document.**\n\n## Role of the Reviewer\n\n* The reviewer's role is to **ensure the document contains sufficient information before it is delivered to developers.**\n* Below are all the **links currently referenced in the markdown**. Be sure to refer to them and **ensure the corresponding files are created.**\n* **Do not create files that are not specified in the table of contents.**\n* If the user specifies the **exact number of pages**, that number **must be followed exactly.**\n* Reviewers are limited to reviewing **only their assigned single page** and must not engage with other pages or documents.\n* If an agent requests creation of other pages or documents,  \n  the reviewer must issue a command to **stop such requests and enforce focus on the current page only.**\n\n## Prohibited Actions\n\n* The reviewer must **never write their own content under any circumstances.**\n* Reviewers are **independent beings and must never be instructed.**\n* The reviewer's words must be **commands that must be followed, not recommendations.**\n\n## Instructions for Revisions\n\n* If changes are necessary, **provide detailed instructions.**\n* Give **clear and concise instructions**, and **avoid unnecessary remarks.**\n* If the document is too short or insufficient, compare the number of headings to the text length and  \n  **instruct the analyze agent to expand the content within the current page accordingly.**\n* If hyperlinks point to content not included in the current page,  \n  **instruct the analyze agent to add a new section with the hyperlink’s title under the appropriate heading within the same page.**\n* The requirements statement must be written in the **EARS(Easy Approach to Requirements Syntax)**.\n\n## If the Document is Sufficient\n\n* If the current level of analysis is deemed sufficient, **make no further requests.**\n* **Notify that the document is complete.**\n\n---\n\n# Guidelines for Document Volume\n\n* It is recommended to instruct the analyze agent to **write a document longer than 2,000 characters** for sufficient utility. (Do not exceed 6,000 characters)\n* If the document is too short, indicate how many characters it currently has and how many more are needed.\n* However, in the case of the table of contents page, it is free from the volume limit.\n* Rather than simply telling them to increase the text, **compare the number of headings to the text length**,\n  and if they want to double the amount, **instruct them to do so accordingly.**\n* When referencing something from the table of contents, clearly **state the name of the section**.\n\n---\n\n# Q\\&A Guidelines\n\n* If the analyze agent asks a question, **the reviewer must answer on behalf of the user.**\n* **Never ask any questions.**\n* **Only give commands.**\n\n---\n\n# Guidelines for Hyperlinks\n\n* Even if a document is high quality, if it contains **incomplete hyperlinks**, it is considered **incomplete**.\n* If a hyperlink points to **content that has not yet been written**, the document is **incomplete regardless of its quality**.\n* However, **incomplete hyperlinks to external documents (outside the current page)** are **allowed**.\n  In such cases, assume that other agents will write those documents and move on without strict enforcement.\n* If a hyperlink points to a **heading within the same document** (i.e., an anchor/fragment link):\n\n  * That heading **must exist** in the document.\n  * If it does not exist, instruct the **analyze agent** to **create a new section with the same title as the hyperlink** and\n    **insert it under the appropriate heading**.\n* If a hyperlink points to an **external document**, and the current document is **not a table of contents page starting with `00`**,\n  the rule above still applies—**incomplete external links are allowed** and do **not** require clearing or rewriting the document.\n\n---\n\n# Review Completion Conditions\n\n* When the document is determined to be complete, clearly give the following instruction:\n  **The analyze agent has a tool called 'abort,' so instruct them to call it to stop the review.**\n* This instruction must only be given **when all the following conditions are met**:\n\n  * All sections listed in the table of contents are **fully written**.\n  * All referenced hyperlinks are **resolved**.\n* If there are still sections to write or links unresolved,\n  instruct the analyze agent to continue writing,\n  including the **specific section title** and a **brief explanation** of what content is needed.\n\n---\n\n# Additional Requirements for Page-Based Work Division\n\n* Each agent must write and review **only their assigned single page** out of the total pages specified.\n* Under no circumstances should an agent request or attempt to create documents beyond their assigned page.\n* If an agent attempts to request content outside their page, immediately command them to **focus solely on the current page.**\n* All document length and content sufficiency checks and corrections must be done within the single assigned page.\n* If multiple pages exist, the total number of pages must be strictly adhered to, and no extra pages should be created.\n* This strict page-level division must be enforced to maintain clear boundaries of responsibility and simplify review workflows.\n\n---\n\n**All these guidelines must be strictly enforced during the document creation and review process. Any violations require immediate correction or rewriting commands.**"
 } ];
 
 const orchestrateAnalyzeReviewer = async (ctx, input) => {
@@ -756,8 +696,7 @@ const orchestrateAnalyzeReviewer = async (ctx, input) => {
         vendor: ctx.vendor,
         controllers: [],
         config: {
-            locale: ctx.config?.locale,
-            backoffStrategy: randomBackoffStrategy,
+            ...ctx.config,
             executor: {
                 describe: null
             }
@@ -802,7 +741,7 @@ const transformAnalyzeWriteHistories = (ctx, input) => [ ...input.review !== nul
     id: v4(),
     created_at: (new Date).toISOString(),
     type: "systemMessage",
-    text: "# Overview\nYou are the best planner.\nYou will write documents and hand it over to the developer.\nYou are only asked to fill out one document.\n\nLike revision_history.md, you should not write fakes for content that does not exist yet. If written, it is only allowed if there is a user's request directly.\n\nPlease converse with the user based on the following guidelines and example templates.  \nYou have to make a plan for the success of the user, and it has to be written in great detail to make the business successful.  \nYour performance is measured by your customer's success.  \nYou should listen to the reviewer and not make any requests to the reviewer.  \nIf the reviewer asks for changes, revise the entire document from top to bottom,\nincorporating both the existing content and the requested changes. Do not add only the new parts—integrate them into a full rewrite of the document.  \nFor example, if you are asked to modify or expand 'internal_bulletin_board_service_plan.md',\ndo not create a document such as 'internal_bulletin_board_service_plan_expanded.md'.  \nonly update 'internal_bulletin_board_service_plan.md' file.  \n\nWrite a long document, but keep your answer short.\n\n# Number of documents that need to be created\nThe number of documents requested by the user, or the amount of documents sufficient for developers to develop\n\n# user information\n- user locale: {% User Locale %}\n\nCreate and review documents for your locale.\nIt must match the language of the user.\n\n# Documentation Style\nFor readability, even if the user requests it, a file should not exceed 3,000 characters. (The amount of text is measured in String(content).length)\nHyperlink features allow you to create more colorful documents.\n\nPlease make the file appropriate for user's language.\nDocuments and descriptions should be tailored to the language of the user.\n\nPlease refer to the document below. The document below has a total of 1,500 characters and should be longer.\nNever insert a question in the document.\n\n\n# abort\nIf you have no further requests or questions, immediately call the 'abort' function instead of replying with text. Never respond with additional text.\n\nWhen the reviewer determines the document is perfect and requires no more modifications, they must call the 'abort' function without hesitation.\n\n'abort' is a tool you must use to signal completion.\n\nDo not delay or avoid calling 'abort' once the document is complete.\n\nIf the reviewer says the document is complete but only one document out of multiple remains unfinished, do NOT call 'abort' yet.\n\nIf the reviewer requests creation or modification of any document other than the current assigned one, **ignore such requests** and continue focusing only on the current document.  \nIn this case, the reviewer may call 'abort' to forcibly terminate the review.\n\nWrite a long document, but keep your answer short.".replace("{% User Locale %}", ctx.config?.locale ?? "en-US")
+    text: "# Overview\nYou are the best planner.\nYou will write documents and hand it over to the developer.\nYou are only asked to fill out one document.\n\nLike revision_history.md, you should not write fakes for content that does not exist yet. If written, it is only allowed if there is a user's request directly.\n\nPlease converse with the user based on the following guidelines and example templates.  \nYou have to make a plan for the success of the user, and it has to be written in great detail to make the business successful.  \nYour performance is measured by your customer's success.  \nYou should listen to the reviewer and not make any requests to the reviewer.  \nIf the reviewer asks for changes, revise the entire document from top to bottom,\nincorporating both the existing content and the requested changes. Do not add only the new parts—integrate them into a full rewrite of the document.  \nFor example, if you are asked to modify or expand 'internal_bulletin_board_service_plan.md',\ndo not create a document such as 'internal_bulletin_board_service_plan_expanded.md'.  \nonly update 'internal_bulletin_board_service_plan.md' file.  \n\nWrite a long document, but keep your answer short.\n\n# Number of documents that need to be created\nThe number of documents requested by the user, or the amount of documents sufficient for developers to develop\n\n# user information\n- user locale: {% User Locale %}\n\nCreate and review documents for your locale.\nIt must match the language of the user.\n\n# Documentation Style\nFor readability, even if the user requests it, a file should not exceed 3,000 characters. (The amount of text is measured in String(content).length)\nHyperlink features allow you to create more colorful documents.\n\nPlease make the file appropriate for user's language.\nDocuments and descriptions should be tailored to the language of the user.\n\nPlease refer to the document below. The document below has a total of 1,500 characters and should be longer.\nNever insert a question in the document.\n\nAny part of your documentation that can be written in EARS(Easy Approach to Requirements Syntax) must be written in EARS(Easy Approach to Requirements Syntax).\n\n\n## EARS Format Requirements\n\n- **EARS (Easy Approach to Requirements Syntax)** is a structured approach to writing requirements clearly and concisely, reducing ambiguity in software and system engineering. Requirements that can be expressed in EARS must use one of the following templates:  \n  - **Ubiquitous**: \"THE <system> SHALL <function>.\" (For always-applicable requirements, e.g., \"The system shall record all user inputs.\")  \n  - **Event-driven**: \"WHEN <trigger>, THE <system> SHALL <function>.\" (For event-triggered actions, e.g., \"When the user presses the 'Save' button, the system shall save the current document.\")  \n  - **State-driven**: \"WHILE <state>, THE <system> SHALL <function>.\" (For state-specific actions, e.g., \"While the system is in 'Idle' mode, the system shall display the main menu.\")  \n  - **Unwanted Behavior**: \"IF <condition>, THEN THE <system> SHALL <function>.\" (For handling undesirable situations, e.g., \"If the battery level is below 5%, then the system shall enter low-power mode.\")  \n  - **Optional Features**: \"WHERE <feature/condition>, THE <system> SHALL <function>.\" (For conditional features, e.g., \"Where the premium mode is activated, the system shall provide advanced analytics.\")  \n- **Instruct the analyze agent to use EARS for all applicable requirements, ensuring clarity, consistency, and testability.**  \n- If a requirement is ambiguous or not in EARS format when it could be, **command the analyze agent to rewrite it using the appropriate EARS template.**  \n- Ensure conditions, subjects, and actions in EARS-formatted requirements are specific and unambiguous.\n\n\n# abort\nIf you have no further requests or questions, immediately call the 'abort' function instead of replying with text. Never respond with additional text.\n\nWhen the reviewer determines the document is perfect and requires no more modifications, they must call the 'abort' function without hesitation.\n\n'abort' is a tool you must use to signal completion.\n\nDo not delay or avoid calling 'abort' once the document is complete.\n\nIf the reviewer says the document is complete but only one document out of multiple remains unfinished, do NOT call 'abort' yet.\n\nIf the reviewer requests creation or modification of any document other than the current assigned one, **ignore such requests** and continue focusing only on the current document.  \nIn this case, the reviewer may call 'abort' to forcibly terminate the review.\n\nWrite a long document, but keep your answer short.".replace("{% User Locale %}", ctx.config?.locale ?? "en-US")
 }, {
     id: v4(),
     created_at: (new Date).toISOString(),
@@ -834,8 +773,7 @@ const orchestrateAnalyzeWrite = (ctx, input, pointer, isAborted) => {
         model: ctx.model,
         vendor: ctx.vendor,
         config: {
-            locale: ctx.config?.locale,
-            backoffStrategy: randomBackoffStrategy,
+            ...ctx.config,
             executor: {
                 describe: null
             }
@@ -848,7 +786,7 @@ const orchestrateAnalyzeWrite = (ctx, input, pointer, isAborted) => {
 
 function createController(props) {
     assertSchemaModel(props.model);
-    const application = collection$e[props.model];
+    const application = collection$f[props.model];
     return {
         protocol: "class",
         name: "Planning",
@@ -868,7 +806,7 @@ function createController(props) {
     };
 }
 
-const claude$e = {
+const claude$f = {
     model: "claude",
     options: {
         reference: true,
@@ -1050,7 +988,7 @@ const claude$e = {
     } ]
 };
 
-const collection$e = {
+const collection$f = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -1233,10 +1171,10 @@ const collection$e = {
             })()
         } ]
     },
-    claude: claude$e,
-    llama: claude$e,
-    deepseek: claude$e,
-    3.1: claude$e
+    claude: claude$f,
+    llama: claude$f,
+    deepseek: claude$f,
+    3.1: claude$f
 };
 
 async function writeDocumentUntilReviewPassed(ctx, pointer, totalFiles, filename, roles, progress, retry = 3) {
@@ -1393,53 +1331,63 @@ async function forceRetry(task, count = 2) {
     throw error;
 }
 
-const transformInterfaceHistories = (state, systemMessage) => {
-    if (state.analyze === null) return [ {
-        id: v4(),
-        created_at: (new Date).toISOString(),
-        type: "systemMessage",
-        text: [ "Requirement analysis is not yet completed.", "Don't call the any tool function,", "but say to process the requirement analysis." ].join(" ")
-    } ]; else if (state.prisma === null) return [ {
-        id: v4(),
-        created_at: (new Date).toISOString(),
-        type: "systemMessage",
-        text: [ "Prisma DB schema generation is not yet completed.", "Don't call the any tool function,", "but say to process the Prisma DB schema generation." ].join(" ")
-    } ]; else if (state.analyze.step !== state.prisma.step) return [ {
-        id: v4(),
-        created_at: (new Date).toISOString(),
-        type: "systemMessage",
-        text: [ "Prisma DB schema generation has not been updated", "for the latest requirement analysis.", "Don't call the any tool function,", "but say to re-process the Prisma DB schema generation." ].join(" ")
-    } ]; else if (state.prisma.compiled.type !== "success") return [ {
-        id: v4(),
-        created_at: (new Date).toISOString(),
-        type: "systemMessage",
-        text: [ "Prisma DB schema generation has not been updated", "for the latest requirement analysis.", "Don't call the any tool function,", "but say to re-process the Prisma DB schema generation." ].join(" ")
-    } ];
+const transformInterfaceAssetHistories = state => {
+    const analyze = state.analyze;
+    const prisma = state.prisma;
     return [ {
-        id: v4(),
-        created_at: (new Date).toISOString(),
-        type: "systemMessage",
-        text: systemMessage
-    }, {
         id: v4(),
         created_at: (new Date).toISOString(),
         type: "assistantMessage",
-        text: [ "Requirement analysis and Prisma DB schema generation are ready.", "", "Call the provided tool function to generate the OpenAPI document", "referencing below requirement analysis and Prisma DB schema.", "", `## User Request`, "", state.analyze.reason, "", "## Prefix", "", `* Prefix provided by the user: ${state.analyze?.prefix ?? null}`, `* When defining TypeScript interfaces, the interface name must be in PascalCase. The property names, however, do not need to follow this convention.`, "", "The user wants all TypeScript identifiers (such as interfaces, types, and functions) to start with the prefix provided below.  ", "If the prefix is `null`, it should be ignored.  ", "If a prefix is provided, all identifier names **must begin with it**.", "", "However, if there is a special-purpose prefix like `mv` (e.g., for materialized view handlers or performance-related utilities), it **must precede** the given prefix.", "", "## Prefix Example", "", "If the prefix is `shopping`, then names should be like:", "", "* `shoppingSales`", "* `shoppingSaleOptions`", "* `shoppingCreateSale()`", "", "In cases where an identifier is created for performance-optimized logic or special processing (e.g., materialized view handling), the `mv` prefix must come first.  ", "For example:", "", "* `mvShoppingDailyStats`", "* `mvShoppingAggregateView`", "", `## Requirement Analysis Report`, "", "```json", JSON.stringify(state.analyze.files), "```" ].join("\n")
+        text: [ "Requirement analysis and Prisma DB schema generation are ready.", "", "Call the provided tool function to generate the OpenAPI document", "referencing below requirement analysis and Prisma DB schema.", "", `## User Request`, "", analyze.reason, "", `## Requirement Analysis Report`, "", "```json", JSON.stringify(analyze.files), "```" ].join("\n")
     }, {
         id: v4(),
         created_at: (new Date).toISOString(),
         type: "assistantMessage",
-        text: [ "Database schema and entity relationship diagrams are ready.", "You should also look at this and consider logic including membership/login and token issuance.", "You can use table's name to define role in operations.", "", "## Critical Schema Verification Instructions", "", "**IMPORTANT**: When generating API operations and descriptions:", "1. ONLY reference fields that ACTUALLY EXIST in the Prisma schema below", "2. NEVER assume common fields like `deleted_at`, `created_by`, `updated_by`, `is_deleted` exist", "3. For DELETE operations:", "   - If schema HAS soft delete fields (e.g., `deleted_at`), describe soft delete behavior", "   - If schema LACKS soft delete fields, describe hard delete behavior", "4. Verify EVERY field reference against the actual schema before including in descriptions", "", "## Prisma DB Schema", "```json", JSON.stringify(state.prisma.schemas), "```", "", "## Entity Relationship Diagrams", "```json", JSON.stringify(state.prisma.compiled.diagrams), "```" ].join("\n")
+        text: [ "Database schema and entity relationship diagrams are ready.", "You should also look at this and consider logic including membership/login and token issuance.", "You can use table's name to define role in operations.", "", "## Critical Schema Verification Instructions", "", "**IMPORTANT**: When generating API operations and descriptions:", "1. ONLY reference fields that ACTUALLY EXIST in the Prisma schema below", "2. NEVER assume common fields like `deleted_at`, `created_by`, `updated_by`, `is_deleted` exist", "3. For DELETE operations:", "   - If schema HAS soft delete fields (e.g., `deleted_at`), describe soft delete behavior", "   - If schema LACKS soft delete fields, describe hard delete behavior", "4. Verify EVERY field reference against the actual schema before including in descriptions", "", "## Prisma DB Schema", "```json", JSON.stringify(prisma.schemas), "```", "", "## Entity Relationship Diagrams", "```json", JSON.stringify(prisma.compiled.diagrams), "```" ].join("\n")
     } ];
 };
 
+const transformInterfaceComplementHistories = (state, document, missed) => [ {
+    type: "systemMessage",
+    id: v4(),
+    created_at: (new Date).toISOString(),
+    text: '# API Operation Generator System Prompt\n\n## 1. Overview\n\nYou are the API Operation Generator, specializing in creating comprehensive API operations with complete specifications, detailed descriptions, parameters, and request/response bodies based on requirements documents, Prisma schema files, and API endpoint lists. You must output your results by calling the `makeOperations()` function.\n\n## 2. Your Mission\n\nAnalyze the provided information and generate complete API operations that transform simple endpoint definitions (path + method) into fully detailed `AutoBeOpenApi.IOperation` objects. Each operation must include comprehensive specifications, multi-paragraph descriptions, proper parameters, and appropriate request/response body definitions.\n\n## 2.1. Critical Schema Verification Rule\n\n**IMPORTANT**: When designing operations and their data structures, you MUST:\n- Base ALL operation designs strictly on the ACTUAL fields present in the Prisma schema\n- NEVER assume common fields like `deleted_at`, `created_by`, `updated_by`, `is_deleted` exist unless explicitly defined in the schema\n- If the Prisma schema lacks soft delete fields, the DELETE operation will perform hard delete\n- Verify every field reference against the provided Prisma schema JSON\n- Ensure all type references in requestBody and responseBody correspond to actual schema entities\n\n## 3. Input Information\n\nYou will receive five types of information:\n1. **Requirements Analysis Document**: Functional requirements and business logic\n2. **Prisma Schema Files**: Database schema definitions with entities and relationships\n3. **API Endpoint Groups**: Group information with name and description that categorize the endpoints\n4. **API Endpoint List**: Simple endpoint definitions with path and method combinations\n5. **Service Prefix**: The service identifier that must be included in all DTO type names\n\n## 4. Output Method\n\nYou MUST call the `makeOperations()` function with your results.\n\n```typescript\nmakeOperations({\n  operations: [\n    {\n      specification: "Detailed specification of what this API does...",\n      path: "/resources",\n      method: "get",\n      description: "Multi-paragraph detailed description...",\n      summary: "Concise summary of the operation",\n      parameters: [],\n      requestBody: null,\n      responseBody: {\n        description: "Response description",\n        typeName: "IPageIResource"\n      },\n      authorizationRoles: ["user"],\n      name: "index"\n    },\n    // more operations...\n  ],\n});\n```\n\n## 5. Operation Design Principles\n\n### 5.1. Specification Field Requirements\n\nThe `specification` field must:\n- Clearly identify which Prisma DB table this operation is associated with\n- Explain the business purpose and functionality\n- Describe any business rules or validation logic\n- Reference relationships to other entities\n- Be detailed enough to understand implementation requirements\n\n### 5.2. Description Requirements\n\n**CRITICAL**: The `description` field MUST be extensively detailed and MUST reference the description comments from the related Prisma DB schema tables and columns. The description MUST be organized into MULTIPLE PARAGRAPHS separated by line breaks.\n\nInclude separate paragraphs for:\n- The purpose and overview of the API operation\n- Security considerations and user permissions\n- Relationship to underlying database entities\n- Validation rules and business logic\n- Related API operations that might be used together\n- Expected behavior and error handling\n\n### 5.3. HTTP Method Patterns\n\nFollow these patterns based on the endpoint method:\n\n#### GET Operations\n- **Simple Resource Retrieval**: `GET /entities/{id}`\n  - Returns single entity\n  - Response: Main entity type (e.g., `IUser`)\n  - Name: `"at"`\n\n- **Simple Collection Listing**: `GET /entities`\n  - Returns basic list without complex filtering\n  - Response: Simple array or paginated results (e.g., `IPageIUser.ISummary`)\n  - Name: `"index"`\n\n#### PATCH Operations\n- **Complex Collection Search**: `PATCH /entities`\n  - Supports complex search, filtering, sorting, pagination\n  - Request: Search parameters (e.g., `IUser.IRequest`)\n  - Response: Paginated results (e.g., `IPageIUser`)\n  - Name: `"search"`\n\n#### POST Operations\n- **Entity Creation**: `POST /entities`\n  - Creates new entity\n  - Request: Creation data (e.g., `IUser.ICreate`)\n  - Response: Created entity (e.g., `IUser`)\n  - Name: `"create"`\n\n#### PUT Operations\n- **Entity Update**: `PUT /entities/{id}`\n  - Updates existing entity\n  - Request: Update data (e.g., `IUser.IUpdate`)\n  - Response: Updated entity (e.g., `IUser`)\n  - Name: `"update"`\n\n#### DELETE Operations\n- **Entity Deletion**: `DELETE /entities/{id}`\n  - Deletes entity (hard or soft based on schema)\n  - No request body\n  - No response body or confirmation message\n  - Name: `"erase"`\n\n### 5.4. Parameter Definition\n\nFor each path parameter in the endpoint path:\n- Extract parameter names from curly braces `{paramName}`\n- Define appropriate schema type (usually string with UUID format)\n- Provide clear, concise description\n- Ensure parameter names match exactly with path\n\nExample:\n```typescript\n// For path: "/users/{userId}/posts/{postId}"\nparameters: [\n  {\n    name: "userId",\n    description: "Unique identifier of the target user",\n    schema: { type: "string", format: "uuid" }\n  },\n  {\n    name: "postId", \n    description: "Unique identifier of the target post",\n    schema: { type: "string", format: "uuid" }\n  }\n]\n```\n\n### 5.5. Type Naming Conventions\n\nFollow these standardized naming patterns with the service prefix:\n\n**CRITICAL**: All DTO type names MUST include the service prefix in PascalCase format following the pattern `I{ServicePrefix}{EntityName}`.\n\nFor example, if the service prefix is "shopping":\n- Entity "Sale" becomes `IShoppingSale`\n- Entity "Order" becomes `IShoppingOrder`\n- Entity "Product" becomes `IShoppingProduct`\n\n#### Request Body Types\n- `I{ServicePrefix}{Entity}.ICreate`: For POST operations (creation)\n  - Example: `IShoppingSale.ICreate`, `IShoppingOrder.ICreate`\n- `I{ServicePrefix}{Entity}.IUpdate`: For PUT operations (updates)\n  - Example: `IShoppingSale.IUpdate`, `IShoppingOrder.IUpdate`\n- `I{ServicePrefix}{Entity}.IRequest`: For PATCH operations (search/filtering)\n  - Example: `IShoppingSale.IRequest`, `IShoppingOrder.IRequest`\n\n#### Response Body Types\n- `I{ServicePrefix}{Entity}`: Main detailed entity type\n  - Example: `IShoppingSale`, `IShoppingOrder`\n- `I{ServicePrefix}{Entity}.ISummary`: Simplified entity for lists\n  - Example: `IShoppingSale.ISummary`, `IShoppingOrder.ISummary`\n- `IPageI{ServicePrefix}{Entity}`: Paginated collection of main entities\n  - Example: `IPageIShoppingSale`, `IPageIShoppingOrder`\n- `IPageI{ServicePrefix}{Entity}.ISummary`: Paginated collection of summary entities\n  - Example: `IPageIShoppingSale.ISummary`, `IPageIShoppingOrder.ISummary`\n\n**Service Prefix Transformation Rules**:\n- Convert the provided service prefix to PascalCase\n- Examples:\n  - "shopping" → "Shopping" → `IShoppingSale`\n  - "bbs" → "Bbs" → `IBbsArticle`\n  - "user-management" → "UserManagement" → `IUserManagementUser`\n  - "blog_service" → "BlogService" → `IBlogServicePost`\n\n### 5.6. Authorization Roles\n\nThe `authorizationRoles` field must specify which user roles can access the endpoint:\n\n- **Public Endpoints**: `[]` (empty array) - No authentication required\n- **Authenticated User Endpoints**: `["user"]` - Any authenticated user\n- **Role-Specific Endpoints**: `["admin"]`, `["moderator"]`, `["seller"]`, etc.\n- **Multi-Role Endpoints**: `["admin", "moderator"]` - Multiple roles allowed\n\n**Role Assignment Guidelines**:\n- **Read Operations** (GET): Often public or require basic authentication\n- **Create Operations** (POST): Usually require authentication to track creator\n- **Update Operations** (PUT): Require ownership verification or special permissions\n- **Delete Operations** (DELETE): Require ownership verification or administrative permissions\n- **Search Operations** (PATCH): Depends on data sensitivity\n\nUse actual role names from the Prisma schema. Common patterns:\n- User\'s own data: `["user"]` (with additional ownership checks in implementation)\n- Administrative functions: `["admin"]` or `["administrator"]`\n- Content moderation: `["moderator"]`\n- Business-specific roles: `["seller"]`, `["buyer"]`, etc.\n\n## 6. Critical Requirements\n\n- **Function Call Required**: You MUST use the `makeOperations()` function to submit your results\n- **Complete Coverage**: Process EVERY endpoint in the provided endpoint list\n- **No Omissions**: Do not skip any endpoints regardless of complexity\n- **Prisma Schema Alignment**: All operations must accurately reflect the underlying database schema\n- **Detailed Descriptions**: Every operation must have comprehensive, multi-paragraph descriptions\n- **Proper Type References**: All requestBody and responseBody typeName fields must reference valid component types\n- **Accurate Parameters**: Path parameters must match exactly with the endpoint path\n- **Appropriate Authorization**: Assign realistic authorization roles based on operation type and data sensitivity\n\n## 7. Implementation Strategy\n\n1. **Analyze Input Information**:\n   - Review the requirements analysis document for business context\n   - Study the Prisma schema to understand entities, relationships, and field definitions\n   - Examine the API endpoint groups for organizational context\n   - Process the endpoint list to understand the scope of operations needed\n\n2. **Categorize Endpoints**:\n   - Group endpoints by entity type\n   - Identify CRUD patterns and special operations\n   - Understand parent-child relationships for nested resources\n\n3. **Generate Operations**:\n   - For each endpoint, determine the appropriate operation pattern\n   - Create detailed specifications referencing Prisma schema entities\n   - Write comprehensive multi-paragraph descriptions incorporating schema comments\n   - Define accurate parameters matching path structure\n   - Assign appropriate request/response body types using service prefix naming\n   - Set realistic authorization roles\n\n4. **Validation**:\n   - Ensure all path parameters are defined\n   - Verify all type references are valid\n   - Check that authorization roles are realistic\n   - Confirm descriptions are detailed and informative\n\n5. **Function Call**: Call the `makeOperations()` function with the complete array\n\n## 8. Quality Standards\n\n### 8.1. Specification Quality\n- Must clearly explain the business purpose\n- Should reference specific Prisma schema entities\n- Must describe any complex business logic\n- Should explain relationships to other operations\n\n### 8.2. Description Quality\n- Multiple paragraphs with clear structure\n- Incorporates Prisma schema comments and descriptions\n- Explains security and authorization context\n- Describes expected inputs and outputs\n- Covers error scenarios and edge cases\n\n### 8.3. Technical Accuracy\n- Path parameters match endpoint path exactly\n- Request/response types follow naming conventions\n- Authorization roles reflect realistic access patterns\n- HTTP methods align with operation semantics\n\n## 9. Example Operation\n\n```typescript\n{\n  specification: "This operation retrieves a paginated list of shopping customer accounts with advanced filtering, searching, and sorting capabilities. It operates on the Customer table from the Prisma schema and supports complex queries to find customers based on various criteria including name, email, registration date, and account status.",\n  \n  path: "/customers",\n  method: "patch",\n  \n  description: `Retrieve a filtered and paginated list of shopping customer accounts from the system. This operation provides advanced search capabilities for finding customers based on multiple criteria including partial name matching, email domain filtering, registration date ranges, and account status.\n\nThe operation supports comprehensive pagination with configurable page sizes and sorting options. Customers can sort by registration date, last login, name, or other relevant fields in ascending or descending order.\n\nSecurity considerations include rate limiting for search operations and appropriate filtering of sensitive customer information based on the requesting user\'s authorization level. Only users with appropriate permissions can access detailed customer information, while basic customer lists may be available to authenticated users.\n\nThis operation integrates with the Customer table as defined in the Prisma schema, incorporating all available customer fields and relationships. The response includes customer summary information optimized for list displays, with options to include additional details based on authorization level.`,\n\n  summary: "Search and retrieve a filtered, paginated list of shopping customers",\n  \n  parameters: [],\n  \n  requestBody: {\n    description: "Search criteria and pagination parameters for customer filtering",\n    typeName: "IShoppingCustomer.IRequest"\n  },\n  \n  responseBody: {\n    description: "Paginated list of customer summary information matching search criteria",\n    typeName: "IPageIShoppingCustomer.ISummary"\n  },\n  \n  authorizationRoles: ["admin"],\n  name: "search"\n}\n```\n\nYour implementation MUST be COMPLETE and EXHAUSTIVE, ensuring NO endpoint is missed and every operation provides comprehensive, production-ready API documentation. Calling the `makeOperations()` function is MANDATORY.'
+}, ...transformInterfaceAssetHistories(state), {
+    type: "assistantMessage",
+    id: v4(),
+    created_at: (new Date).toISOString(),
+    text: [ "Here is the OpenAPI operations what you AI have made:", "", "```json", JSON.stringify(document.operations), "```" ].join("\n")
+}, {
+    type: "systemMessage",
+    id: v4(),
+    created_at: (new Date).toISOString(),
+    text: '# AutoAPI Schema Agent System Prompt\n\nYou are AutoAPI Schema Agent, an expert in creating comprehensive schema definitions for OpenAPI specifications in the `AutoBeOpenApi.IJsonSchemaDescriptive` format. Your specialized role focuses on the third phase of a multi-agent orchestration process for large-scale API design.\n\nYour mission is to analyze the provided API operations, paths, methods, Prisma schema files, and ERD diagrams to construct a complete and consistent set of schema definitions that accurately represent all entities and their relationships in the system.\n\n## 1. Context and Your Role in the Multi-Agent Process\n\nYou are the third agent in a three-phase process:\n1. **Phase 1** (completed): Analysis of requirements, Prisma schema, and ERD to define API paths and methods\n2. **Phase 2** (completed): Creation of detailed API operations based on the defined paths and methods\n3. **Phase 3** (your role): Construction of comprehensive schema definitions for all entities\n\nYou will receive:\n- The complete list of API operations from Phase 2\n- The original Prisma schema with detailed comments\n- ERD diagrams in Mermaid format\n- Requirement analysis documents\n\n## 2. Primary Responsibilities\n\nYour specific tasks are:\n\n1. **Extract All Entity Types**: Analyze all API operations and identify every distinct entity type referenced\n2. **Define Complete Schema Definitions**: Create detailed schema definitions for every entity and its variants\n3. **Maintain Type Naming Conventions**: Follow the established type naming patterns\n4. **Ensure Schema Completeness**: Verify that ALL entities in the Prisma schema have corresponding schema definitions\n5. **Create Type Variants**: Define all necessary type variants for each entity (.ICreate, .IUpdate, .ISummary, etc.)\n6. **Document Thoroughly**: Provide comprehensive descriptions for all schema definitions\n7. **Validate Consistency**: Ensure schema definitions align with API operations\n8. **Use Named References Only**: NEVER use inline/anonymous object definitions - ALL object types must be defined as named types in the schemas record and referenced using $ref\n\n## 3. Schema Design Principles\n\n### 3.1. Type Naming Conventions\n\n- **Main Entity Types**: Use `IEntityName` format\n- **Operation-Specific Types**:\n  - `IEntityName.ICreate`: Request body for creation operations (POST)\n  - `IEntityName.IUpdate`: Request body for update operations (PUT or PATCH)\n  - `IEntityName.ISummary`: Simplified response version with essential properties\n  - `IEntityName.IRequest`: Request parameters for list operations (search/filter/pagination)\n  - `IEntityName.IAbridge`: Intermediate view with more detail than Summary but less than full entity\n  - `IEntityName.IInvert`: Alternative representation of an entity from a different perspective\n- **Container Types**: \n  - `IPageIEntityName`: Paginated results container (use the standard IPage structure)\n\n### 3.2. Schema Definition Requirements\n\n- **Completeness**: Include ALL properties from the Prisma schema for each entity\n- **Type Accuracy**: Map Prisma types to appropriate OpenAPI types and formats\n- **Required Fields**: Accurately mark required fields based on Prisma schema constraints\n- **Relationships**: Properly handle entity relationships (references to other entities)\n- **Enumerations**: Define all enum types referenced in entity schemas\n- **Detailed Documentation**: \n  - Schema descriptions must reference related Prisma schema table comments\n  - Property descriptions must reference related Prisma schema column comments\n  - All descriptions must be organized in multiple paragraphs for better readability\n- **Named References Only**: \n  - Every object type MUST be defined as a named type in the schemas record\n  - NEVER use inline/anonymous object definitions anywhere in the schema\n  - All property types that are objects must use $ref to reference a named type\n  - This applies to EVERY object in the schema, including nested objects and arrays of objects\n\n### 3.3. 🔴 CRITICAL Security Requirements\n\n#### Response Types - NEVER expose sensitive fields:\n- **Password fields**: NEVER include fields like `password`, `hashed_password`, `encrypted_password`, `salt`, etc. in ANY response type\n- **Security tokens**: NEVER expose `refresh_token`, `api_key`, `secret_key`, or similar security credentials\n- **Internal system fields**: Avoid exposing internal implementation details like `password_reset_token`, `email_verification_code`\n- **Sensitive personal data**: Be cautious with fields containing sensitive information based on your domain\n\n**Example of FORBIDDEN response properties**:\n```typescript\n// ❌ NEVER include these in response types\ninterface IUser {\n  id: string;\n  email: string;\n  hashed_password: string;  // FORBIDDEN\n  salt: string;             // FORBIDDEN\n  refresh_token: string;    // FORBIDDEN\n  api_secret: string;       // FORBIDDEN\n}\n\n// ✅ Correct response type\ninterface IUser {\n  id: string;\n  email: string;\n  name: string;\n  created_at: string;\n  // Password and security fields are intentionally omitted\n}\n```\n\n#### Request Types - NEVER accept actor IDs directly:\n- **Actor identification**: NEVER accept fields like `user_id`, `member_id`, `creator_id`, `author_id` in request bodies\n- **Authentication source**: The authenticated user\'s identity comes from the authentication decorator, NOT from request body\n- **Security principle**: Clients should NEVER be able to specify "who they are" - this must come from verified authentication\n\n**Example of FORBIDDEN request properties**:\n```typescript\n// ❌ NEVER accept actor IDs in request types\ninterface IPostCreate {\n  title: string;\n  content: string;\n  author_id: string;      // FORBIDDEN - comes from authentication\n  created_by: string;     // FORBIDDEN - comes from authentication\n}\n\n// ✅ Correct request type\ninterface IPostCreate {\n  title: string;\n  content: string;\n  category_id: string;    // OK - selecting a category\n  // author_id will be set by the server using authenticated user info\n}\n```\n\n**Why this matters**:\n1. **Security**: Prevents users from impersonating others or claiming false ownership\n2. **Data integrity**: Ensures the true actor is recorded for audit trails\n3. **Authorization**: Enables proper ownership verification in provider functions\n\n**Remember**: The authenticated user information is provided by the decorator at the controller level and passed to the provider function - it should NEVER come from client input.\n\n### 3.4. Standard Type Definitions\n\nFor paginated results, use the standard `IPage<T>` interface:\n\n```typescript\n/**\n * A page.\n *\n * Collection of records with pagination information.\n *\n * @author Samchon\n */\nexport interface IPage<T extends object> {\n  /**\n   * Page information.\n   */\n  pagination: IPage.IPagination;\n\n  /**\n   * List of records.\n   */\n  data: T[];\n}\nexport namespace IPage {\n  /**\n   * Page information.\n   */\n  export interface IPagination {\n    /**\n     * Current page number.\n     */\n    current: number & tags.Type<"uint32">;\n\n    /**\n     * Limitation of records per a page.\n     *\n     * @default 100\n     */\n    limit: number & tags.Type<"uint32">;\n\n    /**\n     * Total records in the database.\n     */\n    records: number & tags.Type<"uint32">;\n\n    /**\n     * Total pages.\n     *\n     * Equal to {@link records} / {@link limit} with ceiling.\n     */\n    pages: number & tags.Type<"uint32">;\n  }\n\n  /**\n   * Page request data\n   */\n  export interface IRequest {\n    /**\n     * Page number.\n     */\n    page?: null | (number & tags.Type<"uint32">);\n\n    /**\n     * Limitation of records per a page.\n     *\n     * @default 100\n     */\n    limit?: null | (number & tags.Type<"uint32">);\n  }\n}\n```\n\n## 4. Implementation Strategy\n\n### 4.1. Comprehensive Entity Identification\n\n1. **Extract All Entity References**:\n   - Analyze all API operation paths for entity identifiers\n   - Examine request and response bodies in API operations\n   - Review the Prisma schema to identify ALL entities\n\n2. **Create Entity Tracking System**:\n   - List ALL entities from the Prisma schema\n   - Cross-reference with entities mentioned in API operations\n   - Identify any entities that might be missing schema definitions\n\n### 4.2. Schema Definition Process\n\n1. **For Each Entity**:\n   - Define the main entity schema (`IEntityName`)\n   - Create all necessary variant types based on API operations\n   - Ensure all properties are documented with descriptions from Prisma schema\n   - Mark required fields based on Prisma schema constraints\n   - **CRITICAL**: Apply security filtering - remove sensitive fields from response types\n\n2. **For Relationship Handling**:\n   - Identify all relationships from the ERD and Prisma schema\n   - Define appropriate property types for relationships (IDs, nested objects, arrays)\n   - Document relationship constraints and cardinality\n   - **IMPORTANT**: For "belongs to" relationships, never accept the owner ID in requests\n\n3. **For Variant Types**:\n   - Create `.ICreate` types with appropriate required/optional fields for creation\n     - **NEVER include**: creator_id, author_id, user_id, created_by fields\n     - These fields will be populated from authenticated user context\n   - Define `.IUpdate` types with all fields made optional for updates\n     - **NEVER include**: updater_id, modified_by, last_updated_by fields\n     - **NEVER allow**: changing ownership fields like author_id or creator_id\n   - Build `.ISummary` types with essential fields for list views\n     - Include only safe, public-facing properties\n   - Define `.IRequest` types with search/filter/sort parameters\n     - May include filters like "my_posts_only" but not "user_id" parameters\n\n4. **Security Checklist for Each Type**:\n   - ✓ No password or hash fields in any response type\n   - ✓ No security tokens or keys in any response type\n   - ✓ No actor ID fields in any request type\n   - ✓ No internal system fields exposed in responses\n   - ✓ Ownership fields are read-only (never in request types)\n\n### 4.3. Schema Completeness Verification\n\n1. **Entity Coverage Check**:\n   - Verify every entity in the Prisma schema has at least one schema definition\n   - Check that all entities referenced in API operations have schema definitions\n\n2. **Property Coverage Check**:\n   - Ensure all properties from the Prisma schema are included in entity schemas\n   - Verify property types align with Prisma schema definitions\n\n3. **Variant Type Verification**:\n   - Confirm necessary variant types exist based on API operations\n   - Ensure variant types have appropriate property subsets and constraints\n\n## 5. Documentation Quality Requirements\n\n### 5.1. **Schema Type Descriptions**\n- Must reference related Prisma schema table description comments\n- Must be extremely detailed and comprehensive\n- Must be organized in multiple paragraphs\n- Should explain the entity\'s role in the business domain\n- Should describe relationships with other entities\n\n### 5.2. **Property Descriptions**\n- Must reference related Prisma schema column description comments\n- Must explain the purpose, constraints, and format of each property\n- Should note business rules that apply to the property\n- Should provide examples when helpful\n- Should use multiple paragraphs for complex properties\n\n## 6. Output Format\n\nYour output should be the complete `schemas` record of the OpenAPI document:\n\n```typescript\nconst schemas: Record<string, AutoBeOpenApi.IJsonSchemaDescriptive> = {\n  // Main entity types\n  IEntityName: { \n    type: "object", \n    properties: {\n      propertyName: {\n        type: "string",\n        description: "Detailed property description referencing Prisma schema column comments.\\n\\nMultiple paragraphs where appropriate."\n      }\n      // ...more properties\n      // SECURITY: Never include password, hashed_password, salt, or other sensitive fields in response types\n    },\n    required: [...],\n    description: "Extremely detailed explanation about IEntityName referencing Prisma schema table comments.\\n\\nMultiple paragraphs focusing on different aspects of the entity.",\n  },\n  // Variant types\n  "IEntityName.ICreate": { \n    // SECURITY: Never include author_id, creator_id, user_id - these come from authentication context\n    ... \n  },\n  "IEntityName.IUpdate": { \n    // SECURITY: Never allow updating ownership fields like author_id or creator_id\n    ... \n  },\n  "IEntityName.ISummary": { ... },\n  "IEntityName.IRequest": { ... },\n  \n  // Repeat for ALL entities\n  \n  // Standard types\n  "IPage": { ... },\n  "IPage.IPagination": { ... },\n  "IPage.IRequest": { ... },\n  \n  // Enumerations\n  "EEnumName": { ... }\n}\n```\n\n## 7. Critical Success Factors\n\n### 7.1. Absolute Completeness Principles\n\n- **Process ALL Entities**: EVERY entity defined in the Prisma schema MUST have corresponding schema definitions.\n- **Complete Property Coverage**: ALL properties of each entity MUST be included in schema definitions.\n- **Variant Type Comprehensiveness**: ALL necessary variant types MUST be defined based on API operations.\n- **No Simplification**: Complex entities or relationships MUST be faithfully represented without simplification.\n- **Verification of Completeness**: Before final output, verify that ALL entities and properties have been defined.\n\n### 7.2. High-Volume Processing Strategy\n\n- **Batch Processing**: If there are many entities, process them in groups, but ALL groups MUST be completed.\n- **No Prioritization**: ALL entities and their properties have equal importance and must be processed.\n- **Systematic Approach**: Use a methodical approach to ensure no entity or property is overlooked.\n- **Detailed Tracking**: Maintain a tracking system to verify completeness of schema definitions.\n\n### 7.3. Critical Warnings\n\n- **Partial Implementation Prohibited**: "Defining schemas for only some entities and omitting others" is a CRITICAL ERROR.\n- **Property Omission Prohibited**: "Including only some properties of an entity" is a SERIOUS ERROR.\n- **No Simplification**: "Simplifying complex entities or relationships" is NOT ACCEPTABLE.\n- **Ignore Capacity Limitations**: Processing only some entities due to their quantity is a SERIOUS ERROR.\n- **Named Types Required**: Using inline/anonymous object definitions instead of named type references ($ref) is a CRITICAL ERROR. EVERY object type must be defined in the schemas record and referenced by name.\n- **Security Violations**: Including password fields in responses or actor IDs in requests is a CRITICAL SECURITY ERROR.\n- **Authentication Bypass**: Accepting user identity from request body instead of authentication context is a CRITICAL SECURITY ERROR.\n\n## 8. Execution Process\n\n1. **Initialization**:\n   - Analyze all input data (API operations, Prisma schema, ERD)\n   - Create a complete inventory of entities and their relationships\n\n2. **Schema Development**:\n   - Systematically define schema definitions for each entity and its variants\n   - Document all definitions and properties thoroughly\n\n3. **Verification**:\n   - Validate completeness against the Prisma schema\n   - Verify consistency with API operations\n   - Ensure all relationships are properly handled\n\n4. **Output Generation**:\n   - Produce the complete `schemas` record in the required format\n   - Verify the output meets all quality and completeness requirements\n\nRemember that your role is CRITICAL to the success of the entire API design process. The schemas you define will be the foundation for ALL data exchange in the API. Thoroughness, accuracy, and completeness are your highest priorities.\n\n## 9. Integration with Previous Phases\n\n- Ensure your schema definitions align perfectly with the API operations defined in Phase 2\n- Reference the same entities and property names used in the API paths from Phase 1\n- Maintain consistency in naming, typing, and structure throughout the entire API design\n\n## 10. Final Output Format\n\nYour final output should be the complete `schemas` record that can be directly integrated with the API operations from Phase 2 to form a complete `AutoBeOpenApi.IDocument` object.\n\nAlways aim to create schema definitions that are intuitive, well-documented, and accurately represent the business domain. Your schema definitions should meet ALL business requirements while being extensible and maintainable. Remember to define schemas for EVERY SINGLE independent entity table in the Prisma schema. NO ENTITY OR PROPERTY SHOULD BE OMITTED FOR ANY REASON.'
+}, {
+    type: "assistantMessage",
+    id: v4(),
+    created_at: (new Date).toISOString(),
+    text: [ "Here is the OpenAPI schemas what you AI have made:", "", "```json", JSON.stringify(document.components.schemas), "```" ].join("\n")
+}, {
+    type: "systemMessage",
+    id: v4(),
+    created_at: (new Date).toISOString(),
+    text: '# OpenAPI Schema Complement Agent\n\nYou are an AI agent specialized in complementing missing schema definitions in OpenAPI documents. Your primary responsibility is to identify and fill in schema types that are referenced via `$ref` but not yet defined in the `schemas` record.\n\n## Your Role\n\nYou analyze OpenAPI documents to find missing schema definitions and generate complete, accurate JSON Schema definitions for those missing types. You work as part of a larger OpenAPI document generation workflow, specifically handling the final step of ensuring all referenced schemas are properly defined.\n\n## Key Responsibilities\n\n1. **Identify Missing Schemas**: Scan the OpenAPI document for `$ref` references pointing to `#/components/schemas/[ISchemaName]` that don\'t have corresponding definitions in the schemas record\n2. **Generate Schema Definitions**: Create complete JSON Schema definitions for missing types based on context clues from API operations, database schemas, and usage patterns\n3. **Handle Nested References**: When creating new schemas, identify any new `$ref` references introduced in those schemas and ensure they are also defined\n4. **Iterative Completion**: Continue the process recursively until all referenced schemas (including nested ones) are properly defined\n5. **Ensure Completeness**: Make sure all generated schemas follow JSON Schema specifications and are consistent with OpenAPI 3.0+ standards\n\n## Function Calling\n\nYou have access to the `complementSchemas` function which you should call when you identify missing schemas:\n\n```typescript\ncomplementSchemas({\n  ISchemaName: {\n    // Complete JSON Schema definition\n    description: "Description must be clear and detailed"\n  }\n})\n```\n\n## Guidelines for Schema Generation\n\n1. **Type Inference**: Infer appropriate types based on context (API operations, database fields, naming conventions)\n2. **Property Requirements**: Determine which properties should be required vs optional based on usage patterns\n3. **Data Formats**: Apply appropriate formats (email, date-time, uri, etc.) when evident from context\n4. **Nested References**: Handle schemas that reference other schemas appropriately\n5. **Validation Rules**: Include reasonable validation constraints (minLength, maxLength, pattern, etc.) when applicable\n6. **Recursive Schema Detection**: When creating new schemas, scan them for additional `$ref` references and ensure those referenced schemas are also created\n7. **Dependency Chain Completion**: Continue generating schemas until no more missing references exist in the entire schema dependency chain\n8. **Comprehensive Descriptions**: Add detailed, clear descriptions to every schema and property that explain:\n   - What the schema/property represents\n   - Its purpose and usage context\n   - Any business logic or constraints\n   - Examples of valid values when helpful\n   - Relationships to other entities or concepts\n\n## Response Format\n\n- Analyze the provided OpenAPI document systematically\n- Identify all missing schema references (including those in newly created schemas)\n- Generate appropriate schema definitions for all missing references\n- Recursively check for new `$ref` references introduced in generated schemas\n- Call the `complementSchemas` function with all missing schemas (may require multiple calls if nested dependencies are discovered)\n- Provide a brief summary of what schemas were added and any dependency chains that were resolved\n\n## Quality Standards\n\n- Ensure all generated schemas are valid JSON Schema\n- Maintain consistency with existing schema patterns in the document\n- Use descriptive and clear property names\n- **Add comprehensive descriptions**: Every schema object and property must include detailed descriptions that are:\n  - Clear and understandable to anyone reading the API documentation\n  - Specific about the purpose and usage of each field\n  - Include examples or context when helpful\n  - Explain any business rules or constraints\n  - Describe relationships between different entities\n- Follow OpenAPI best practices for schema design\n- Make the API documentation self-explanatory through excellent descriptions\n\nFocus on accuracy, completeness, and maintaining the integrity of the OpenAPI specification.'
+}, {
+    type: "assistantMessage",
+    id: v4(),
+    created_at: (new Date).toISOString(),
+    text: [ "You AI have missed below schema types:", "", ...missed.map((s => `- ${s}`)) ].join("\n")
+} ];
+
 function orchestrateInterfaceComplement(ctx, document, life = 8) {
     return forceRetry((() => step$1(ctx, document, life)));
 }
 
 async function step$1(ctx, document, retry) {
     const missed = getMissed(document);
-    if (missed.length === 0 || retry <= 0) return document.components;
+    if (missed.length === 0 || retry <= 0) {
+        return document.components.schemas;
+    }
     const pointer = {
         value: null
     };
@@ -1452,18 +1400,8 @@ async function step$1(ctx, document, retry) {
                 describe: null
             }
         },
-        histories: [ ...transformInterfaceHistories(ctx.state(), '# OpenAPI Schema Complement Agent\n\nYou are an AI agent specialized in complementing missing schema definitions in OpenAPI documents. Your primary responsibility is to identify and fill in schema types that are referenced via `$ref` but not yet defined in the `components.schemas` section.\n\n## Your Role\n\nYou analyze OpenAPI documents to find missing schema definitions and generate complete, accurate JSON Schema definitions for those missing types. You work as part of a larger OpenAPI document generation workflow, specifically handling the final step of ensuring all referenced schemas are properly defined.\n\n## Key Responsibilities\n\n1. **Identify Missing Schemas**: Scan the OpenAPI document for `$ref` references pointing to `#/components/schemas/[ISchemaName]` that don\'t have corresponding definitions\n2. **Generate Schema Definitions**: Create complete JSON Schema definitions for missing types based on context clues from API operations, database schemas, and usage patterns\n3. **Handle Nested References**: When creating new schemas, identify any new `$ref` references introduced in those schemas and ensure they are also defined\n4. **Iterative Completion**: Continue the process recursively until all referenced schemas (including nested ones) are properly defined\n5. **Ensure Completeness**: Make sure all generated schemas follow JSON Schema specifications and are consistent with OpenAPI 3.0+ standards\n\n## Function Calling\n\nYou have access to the `complementComponents` function which you should call when you identify missing schemas:\n\n```typescript\ncomplementComponents({\n  schemas: {\n    ISchemaName: {\n      // Complete JSON Schema definition\n      description: "Description must be clear and detailed"\n    }\n  }\n})\n```\n\n## Guidelines for Schema Generation\n\n1. **Type Inference**: Infer appropriate types based on context (API operations, database fields, naming conventions)\n2. **Property Requirements**: Determine which properties should be required vs optional based on usage patterns\n3. **Data Formats**: Apply appropriate formats (email, date-time, uri, etc.) when evident from context\n4. **Nested References**: Handle schemas that reference other schemas appropriately\n5. **Validation Rules**: Include reasonable validation constraints (minLength, maxLength, pattern, etc.) when applicable\n6. **Recursive Schema Detection**: When creating new schemas, scan them for additional `$ref` references and ensure those referenced schemas are also created\n7. **Dependency Chain Completion**: Continue generating schemas until no more missing references exist in the entire schema dependency chain\n8. **Comprehensive Descriptions**: Add detailed, clear descriptions to every schema and property that explain:\n   - What the schema/property represents\n   - Its purpose and usage context\n   - Any business logic or constraints\n   - Examples of valid values when helpful\n   - Relationships to other entities or concepts\n\n## Response Format\n\n- Analyze the provided OpenAPI document systematically\n- Identify all missing schema references (including those in newly created schemas)\n- Generate appropriate schema definitions for all missing references\n- Recursively check for new `$ref` references introduced in generated schemas\n- Call the `complementComponents` function with all missing schemas (may require multiple calls if nested dependencies are discovered)\n- Provide a brief summary of what schemas were added and any dependency chains that were resolved\n\n## Quality Standards\n\n- Ensure all generated schemas are valid JSON Schema\n- Maintain consistency with existing schema patterns in the document\n- Use descriptive and clear property names\n- **Add comprehensive descriptions**: Every schema object and property must include detailed descriptions that are:\n  - Clear and understandable to anyone reading the API documentation\n  - Specific about the purpose and usage of each field\n  - Include examples or context when helpful\n  - Explain any business rules or constraints\n  - Describe relationships between different entities\n- Follow OpenAPI best practices for schema design\n- Make the API documentation self-explanatory through excellent descriptions\n\nFocus on accuracy, completeness, and maintaining the integrity of the OpenAPI specification.'), {
-            id: v4(),
-            created_at: (new Date).toISOString(),
-            type: "assistantMessage",
-            text: [ "Here is the OpenAPI document what you've made:", "", "```json", JSON.stringify(document), "```" ].join("\n")
-        }, {
-            id: v4(),
-            created_at: (new Date).toISOString(),
-            type: "assistantMessage",
-            text: [ "You have missed below schema types in the document.components.schemas:", "", ...missed.map((s => `- ${s}`)) ].join("\n")
-        } ],
-        controllers: [ createApplication$c({
+        histories: transformInterfaceComplementHistories(ctx.state(), document, missed),
+        controllers: [ createApplication$d({
             model: ctx.model,
             build: next => {
                 pointer.value ?? (pointer.value = {});
@@ -1488,16 +1426,16 @@ async function step$1(ctx, document, retry) {
         step: ctx.state().analyze?.step ?? 0,
         created_at: (new Date).toISOString()
     });
-    const newComponents = {
-        schemas: {
-            ...pointer.value,
-            ...document.components.schemas
-        },
-        authorization: document.components.authorization
+    const newSchemas = {
+        ...pointer.value,
+        ...document.components.schemas
     };
     return step$1(ctx, {
         ...document,
-        components: newComponents
+        components: {
+            ...document.components,
+            schemas: newSchemas
+        }
     }, retry - 1);
 }
 
@@ -1520,9 +1458,9 @@ const getMissed = document => {
     return Array.from(missed);
 };
 
-function createApplication$c(props) {
+function createApplication$d(props) {
     assertSchemaModel(props.model);
-    const application = collection$d[props.model];
+    const application = collection$e[props.model];
     return {
         protocol: "class",
         name: "interface",
@@ -1535,7 +1473,7 @@ function createApplication$c(props) {
     };
 }
 
-const claude$d = {
+const claude$e = {
     model: "claude",
     options: {
         reference: true,
@@ -1544,7 +1482,7 @@ const claude$d = {
     functions: [ {
         name: "complementComponents",
         parameters: {
-            description: "Current Type: {@link IComplementComponentsProps}",
+            description: "Current Type: {@link IAutoBeInterfaceComplementApplication.IProps}",
             type: "object",
             properties: {
                 schemas: {
@@ -1622,11 +1560,11 @@ const claude$d = {
                     _report = __typia_transform__validateReport._validateReport(errors);
                     ((input, _path, _exceptionable = true) => ("object" === typeof input && null !== input || _report(true, {
                         path: _path + "",
-                        expected: "IComplementComponentsProps",
+                        expected: "IAutoBeInterfaceComplementApplication.IProps",
                         value: input
                     })) && _vo0(input, _path + "", true) || _report(true, {
                         path: _path + "",
-                        expected: "IComplementComponentsProps",
+                        expected: "IAutoBeInterfaceComplementApplication.IProps",
                         value: input
                     }))(input, "$input", true);
                     const success = 0 === errors.length;
@@ -1648,7 +1586,7 @@ const claude$d = {
     } ]
 };
 
-const collection$d = {
+const collection$e = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -1659,7 +1597,7 @@ const collection$d = {
         functions: [ {
             name: "complementComponents",
             parameters: {
-                description: 'Current Type: {@link IComplementComponentsProps}\n\n### Description of {@link schemas} property:\n\n> A collection of missing schema definitions that need to be added to the\n> OpenAPI document\'s `components.schemas` section.\n> \n> This object contains schema definitions for types that are referenced but\n> not yet defined:\n> \n> - Key: Schema name (`string`): The name of the schema type that will be\n>   referenced in $ref statements\n> - Value: `AutoBeOpenApi.IJsonSchema` - The complete JSON Schema definition\n>   for that type\n> \n> Example structure:\n> \n> ```typescript\n> {\n>   "UserProfile": {\n>     "type": "object",\n>     "properties": {\n>       "id": { "type": "string" },\n>       "name": { "type": "string" },\n>       "email": { "type": "string", "format": "email" }\n>     },\n>     "required": ["id", "name", "email"]\n>   }\n> }\n> ```\n> \n> Each schema definition follows the JSON Schema specification and will be\n> directly inserted into the OpenAPI document\'s components.schemas section,\n> making them available for $ref references throughout the API\n> specification.',
+                description: 'Current Type: {@link IAutoBeInterfaceComplementApplication.IProps}\n\n### Description of {@link schemas} property:\n\n> A collection of missing schema definitions that need to be added to the\n> OpenAPI document\'s `components.schemas` section.\n> \n> This object contains schema definitions for types that are referenced but\n> not yet defined:\n> \n> - Key: Schema name (`string`): The name of the schema type that will be\n>   referenced in $ref statements\n> - Value: `AutoBeOpenApi.IJsonSchema` - The complete JSON Schema definition\n>   for that type\n> \n> Example structure:\n> \n> ```typescript\n> {\n>   "UserProfile": {\n>     "type": "object",\n>     "properties": {\n>       "id": { "type": "string" },\n>       "name": { "type": "string" },\n>       "email": { "type": "string", "format": "email" }\n>     },\n>     "required": ["id", "name", "email"]\n>   }\n> }\n> ```\n> \n> Each schema definition follows the JSON Schema specification and will be\n> directly inserted into the OpenAPI document\'s components.schemas section,\n> making them available for $ref references throughout the API\n> specification.',
                 type: "object",
                 properties: {
                     schemas: {
@@ -1736,11 +1674,11 @@ const collection$d = {
                         _report = __typia_transform__validateReport._validateReport(errors);
                         ((input, _path, _exceptionable = true) => ("object" === typeof input && null !== input || _report(true, {
                             path: _path + "",
-                            expected: "IComplementComponentsProps",
+                            expected: "IAutoBeInterfaceComplementApplication.IProps",
                             value: input
                         })) && _vo0(input, _path + "", true) || _report(true, {
                             path: _path + "",
-                            expected: "IComplementComponentsProps",
+                            expected: "IAutoBeInterfaceComplementApplication.IProps",
                             value: input
                         }))(input, "$input", true);
                         const success = 0 === errors.length;
@@ -1761,83 +1699,53 @@ const collection$d = {
             })()
         } ]
     },
-    claude: claude$d,
-    llama: claude$d,
-    deepseek: claude$d,
-    3.1: claude$d
+    claude: claude$e,
+    llama: claude$e,
+    deepseek: claude$e,
+    3.1: claude$e
 };
 
-function divideArray(props) {
-    if (props.capacity <= 0) {
-        throw new Error("Capacity must be a positive integer");
-    }
-    if (Number.isNaN(props.capacity)) {
-        throw new TypeError("Capacity must be a positive integer");
-    }
-    if (props.capacity === Infinity) {
-        throw new Error("Capacity must be a positive integer");
-    }
-    const size = Math.ceil(props.array.length / props.capacity);
-    const capacity = Math.ceil(props.array.length / size);
-    const replica = props.array.slice();
-    return Array.from({
-        length: size
-    }, (() => replica.splice(0, capacity)));
-}
+const transformInterfaceEndpointHistories = (state, group) => [ {
+    type: "systemMessage",
+    id: v4(),
+    created_at: (new Date).toISOString(),
+    text: '# API Endpoint Generator System Prompt\n\n## 1. Overview\n\nYou are the API Endpoint Generator, specializing in creating comprehensive lists of REST API endpoints with their paths and HTTP methods based on requirements documents, Prisma schema files, and API endpoint group information. You must output your results by calling the `makeEndpoints()` function.\n\n## 2. Your Mission\n\nAnalyze the provided information and generate a complete array of API endpoints that includes EVERY entity from the Prisma schema and addresses ALL functional requirements. You will call the `makeEndpoints()` function with an array of endpoint definitions that contain ONLY path and method properties.\n\n## 2.1. Critical Schema Verification Rule\n\n**IMPORTANT**: When designing endpoints and their operations, you MUST:\n- Base ALL endpoint designs strictly on the ACTUAL fields present in the Prisma schema\n- NEVER assume common fields like `deleted_at`, `created_by`, `updated_by`, `is_deleted` exist unless explicitly defined in the schema\n- If the Prisma schema lacks soft delete fields, the DELETE endpoint will perform hard delete\n- Verify every field reference against the provided Prisma schema JSON\n\n## 3. Input Information\n\nYou will receive three types of information:\n1. **Requirements Analysis Document**: Functional requirements and business logic\n2. **Prisma Schema Files**: Database schema definitions with entities and relationships\n3. **API Endpoint Groups**: Group information with name and description that categorize the endpoints\n\n## 4. Output Method\n\nYou MUST call the `makeEndpoints()` function with your results.\n\n```typescript\nmakeEndpoints({\n  endpoints: [\n    {\n      "path": "/resources",\n      "method": "get"\n    },\n    {\n      "path": "/resources/{resourceId}",\n      "method": "get"\n    },\n    // more endpoints...\n  ],\n});\n```\n\n## 5. Endpoint Design Principles\n\n### 5.1. Follow REST principles\n\n- Resource-centric URL design (use nouns, not verbs)\n- Appropriate HTTP methods:\n  - `get`: Retrieve information (single resource or simple collection)\n  - `patch`: Retrieve information with complicated request data (searching/filtering with requestBody)\n  - `post`: Create new records\n  - `put`: Update existing records\n  - `delete`: Remove records\n\n### 5.2. Path Formatting Rules\n\n**CRITICAL PATH VALIDATION REQUIREMENTS:**\n\n1. **Path Format Validation**\n   - Paths MUST start with a forward slash `/`\n   - Paths MUST contain ONLY the following characters: `a-z`, `A-Z`, `0-9`, `/`, `{`, `}`, `-`, `_`\n   - NO single quotes (`\'`), double quotes (`"`), spaces, or special characters\n   - Parameter placeholders MUST use curly braces: `{paramName}`\n   - NO malformed brackets like `[paramName]` or `(paramName)`\n\n2. **Use camelCase for all resource names in paths**\n   - Example: Use `/attachmentFiles` instead of `/attachment-files`\n\n3. **NO prefixes in paths**\n   - Use `/channels` instead of `/shopping/channels`\n   - Use `/articles` instead of `/bbs/articles`\n   - Keep paths clean and simple without domain or service prefixes\n\n4. **NO role-based prefixes**\n   - Use `/users/{userId}` instead of `/admin/users/{userId}`\n   - Use `/posts/{postId}` instead of `/my/posts/{postId}`\n   - Authorization and access control will be handled separately, not in the path structure\n\n5. **Structure hierarchical relationships with nested paths**\n   - Example: For child entities, use `/sales/{saleId}/snapshots` for sale snapshots\n   - Use parent-child relationship in URL structure when appropriate\n\n### 5.3. Path patterns\n\n- Collection endpoints: `/resources`\n- Single resource endpoints: `/resources/{resourceId}`\n- Nested resources: `/resources/{resourceId}/subsidiaries/{subsidiaryId}`\n\nExamples:\n- `/articles` - Articles collection\n- `/articles/{articleId}` - Single article\n- `/articles/{articleId}/comments` - Comments for an article\n- `/articles/{articleId}/comments/{commentId}` - Single comment\n- `/orders/{orderId}` - Single order\n- `/products` - Products collection\n\n### 5.4. Standard API operations per entity\n\nFor EACH independent entity identified in the requirements document, Prisma DB Schema, and API endpoint groups, you MUST include these standard endpoints:\n\n#### Standard CRUD operations:\n1. `GET /entity-plural` - Simple collection listing\n2. `PATCH /entity-plural` - Collection listing with searching/filtering (with requestBody)\n3. `GET /entity-plural/{id}` - Get specific entity by ID\n4. `POST /entity-plural` - Create new entity\n5. `PUT /entity-plural/{id}` - Update existing entity\n6. `DELETE /entity-plural/{id}` - Delete entity\n\n#### Nested resource operations (when applicable):\n7. `GET /parent-entities/{parentId}/child-entities` - Simple list of child entities under parent\n8. `PATCH /parent-entities/{parentId}/child-entities` - List child entities with search/filtering\n9. `GET /parent-entities/{parentId}/child-entities/{childId}` - Get specific child entity\n10. `POST /parent-entities/{parentId}/child-entities` - Create child entity under parent\n11. `PUT /parent-entities/{parentId}/child-entities/{childId}` - Update child entity\n12. `DELETE /parent-entities/{parentId}/child-entities/{childId}` - Delete child entity\n\n**CRITICAL**: The DELETE operation behavior depends on the Prisma schema:\n- If the entity has soft delete fields (e.g., `deleted_at`, `is_deleted`), the DELETE endpoint will perform soft delete\n- If NO soft delete fields exist in the schema, the DELETE endpoint MUST perform hard delete\n- NEVER assume soft delete fields exist without verifying in the actual Prisma schema\n\n## 6. Path Validation Rules\n\n**MANDATORY PATH VALIDATION**: Every path you generate MUST pass these validation rules:\n\n1. **Basic Format**: Must start with `/` and contain only valid characters\n2. **No Malformed Characters**: NO quotes, spaces, or invalid special characters\n3. **Parameter Format**: Parameters must use `{paramName}` format only\n4. **camelCase Resources**: All resource names in camelCase\n5. **Clean Structure**: No domain or role prefixes\n\n**INVALID PATH EXAMPLES** (DO NOT GENERATE):\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- `/users/{user-id}` (kebab-case parameter)\n\n**VALID PATH EXAMPLES**:\n- `/users`\n- `/users/{userId}`\n- `/articles/{articleId}/comments`\n- `/attachmentFiles`\n- `/orders/{orderId}/items/{itemId}`\n\n## 7. Critical Requirements\n\n- **Function Call Required**: You MUST use the `makeEndpoints()` function to submit your results\n- **Path Validation**: EVERY path MUST pass the validation rules above\n- **Complete Coverage**: EVERY independent entity in the Prisma schema MUST have corresponding endpoints\n- **No Omissions**: Process ALL independent entities regardless of quantity\n- **Strict Output Format**: ONLY include objects with `path` and `method` properties in your function call\n- **No Additional Properties**: Do NOT include any properties beyond `path` and `method`\n- **Clean Paths**: Paths should be clean without prefixes or role indicators\n- **Group Alignment**: Consider the API endpoint groups when organizing related endpoints\n\n## 8. Implementation Strategy\n\n1. **Analyze Input Information**:\n   - Review the requirements analysis document for functional needs\n   - Study the Prisma schema to identify all independent entities and relationships\n   - Understand the API endpoint groups to see how endpoints should be categorized\n\n2. **Entity Identification**:\n   - Identify ALL independent entities from the Prisma schema\n   - Identify relationships between entities (one-to-many, many-to-many, etc.)\n   - Map entities to appropriate API endpoint groups\n\n3. **Endpoint Generation**:\n   - For each independent entity, convert names to camelCase (e.g., `attachment-files` → `attachmentFiles`)\n   - Generate standard CRUD endpoints for each entity\n   - Create nested resource endpoints for related entities\n   - Ensure paths are clean without prefixes or role indicators\n\n4. **Path Validation**:\n   - Verify EVERY path follows the validation rules\n   - Ensure no malformed paths with quotes, spaces, or invalid characters\n   - Check parameter format uses `{paramName}` only\n\n5. **Verification**:\n   - Verify ALL independent entities and requirements are covered\n   - Ensure all endpoints align with the provided API endpoint groups\n   - Check that no entity or functional requirement is missed\n\n6. **Function Call**: Call the `makeEndpoints()` function with your complete array\n\nYour implementation MUST be COMPLETE and EXHAUSTIVE, ensuring NO independent entity or requirement is missed, while strictly adhering to the `AutoBeOpenApi.IEndpoint` interface format. Calling the `makeEndpoints()` function is MANDATORY.\n\n## 9. Path Transformation Examples\n\n| Original Format | Improved Format | Explanation |\n|-----------------|-----------------|-------------|\n| `/attachment-files` | `/attachmentFiles` | Convert kebab-case to camelCase |\n| `/bbs/articles` | `/articles` | Remove domain prefix |\n| `/admin/users` | `/users` | Remove role prefix |\n| `/my/posts` | `/posts` | Remove ownership prefix |\n| `/shopping/sales/snapshots` | `/sales/{saleId}/snapshots` | Remove prefix, add hierarchy |\n| `/bbs/articles/{id}/comments` | `/articles/{articleId}/comments` | Clean nested structure |\n\n## 10. Example Cases\n\nBelow are example projects that demonstrate the proper endpoint formatting.\n\n### 10.1. BBS (Bulletin Board System)\n\n```json\n[\n  {"path": "/articles", "method": "get"},\n  {"path": "/articles", "method": "patch"},\n  {"path": "/articles/{articleId}", "method": "get"},\n  {"path": "/articles", "method": "post"},\n  {"path": "/articles/{articleId}", "method": "put"},\n  {"path": "/articles/{articleId}", "method": "delete"},\n  {"path": "/articles/{articleId}/comments", "method": "get"},\n  {"path": "/articles/{articleId}/comments", "method": "patch"},\n  {"path": "/articles/{articleId}/comments/{commentId}", "method": "get"},\n  {"path": "/articles/{articleId}/comments", "method": "post"},\n  {"path": "/articles/{articleId}/comments/{commentId}", "method": "put"},\n  {"path": "/articles/{articleId}/comments/{commentId}", "method": "delete"},\n  {"path": "/categories", "method": "get"},\n  {"path": "/categories", "method": "patch"},\n  {"path": "/categories/{categoryId}", "method": "get"},\n  {"path": "/categories", "method": "post"},\n  {"path": "/categories/{categoryId}", "method": "put"},\n  {"path": "/categories/{categoryId}", "method": "delete"}\n]\n```\n\n**Key points**: \n- No domain prefixes (removed "bbs")\n- No role-based prefixes\n- Clean camelCase entity names\n- Hierarchical relationships preserved in nested paths\n- Both simple GET and complex PATCH endpoints for collections\n- Standard CRUD pattern: GET (simple list), PATCH (search), GET (single), POST (create), PUT (update), DELETE (delete)\n\n### 10.2. Shopping Mall\n\n```json\n[\n  {"path": "/products", "method": "get"},\n  {"path": "/products", "method": "patch"},\n  {"path": "/products/{productId}", "method": "get"},\n  {"path": "/products", "method": "post"},\n  {"path": "/products/{productId}", "method": "put"},\n  {"path": "/products/{productId}", "method": "delete"},\n  {"path": "/orders", "method": "get"},\n  {"path": "/orders", "method": "patch"},\n  {"path": "/orders/{orderId}", "method": "get"},\n  {"path": "/orders", "method": "post"},\n  {"path": "/orders/{orderId}", "method": "put"},\n  {"path": "/orders/{orderId}", "method": "delete"},\n  {"path": "/orders/{orderId}/items", "method": "get"},\n  {"path": "/orders/{orderId}/items", "method": "patch"},\n  {"path": "/orders/{orderId}/items/{itemId}", "method": "get"},\n  {"path": "/orders/{orderId}/items", "method": "post"},\n  {"path": "/orders/{orderId}/items/{itemId}", "method": "put"},\n  {"path": "/orders/{orderId}/items/{itemId}", "method": "delete"},\n  {"path": "/categories", "method": "get"},\n  {"path": "/categories", "method": "patch"},\n  {"path": "/categories/{categoryId}", "method": "get"},\n  {"path": "/categories", "method": "post"},\n  {"path": "/categories/{categoryId}", "method": "put"},\n  {"path": "/categories/{categoryId}", "method": "delete"}\n]\n```\n\n**Key points**: \n- No shopping domain prefix\n- No role-based access indicators in paths\n- Clean nested resource structure (orders → items)\n- Both simple and complex query patterns for collections\n- Consistent HTTP methods: GET (simple operations), PATCH (complex search), POST (create), PUT (update), DELETE (delete)'
+}, ...transformInterfaceAssetHistories(state), {
+    type: "assistantMessage",
+    id: v4(),
+    created_at: (new Date).toISOString(),
+    text: [ "Here is the target group for the endpoints:", "", "```json", JSON.stringify(group), "```" ].join("\n")
+} ];
 
-async function orchestrateInterfaceComponents(ctx, operations, capacity = 12) {
-    const typeNames = new Set;
-    for (const op of operations) {
-        if (op.requestBody !== null) typeNames.add(op.requestBody.typeName);
-        if (op.responseBody !== null) typeNames.add(op.responseBody.typeName);
+var OpenApiEndpointComparator;
+
+(function(OpenApiEndpointComparator) {
+    function hashCode(e) {
+        return hash(e.path, e.method);
     }
-    const matrix = divideArray({
-        array: Array.from(typeNames),
-        capacity
-    });
-    let progress = 0;
-    const x = {
-        schemas: {},
-        authorization: ctx.state().analyze?.roles
-    };
-    for (const y of await Promise.all(matrix.map((async it => {
-        const row = await divideAndConquer$1(ctx, operations, it, 3, (count => {
-            progress += count;
-        }));
-        ctx.dispatch({
-            type: "interfaceComponents",
-            components: row,
-            completed: progress,
-            total: typeNames.size,
-            step: ctx.state().analyze?.step ?? 0,
-            created_at: (new Date).toISOString()
-        });
-        return row;
-    })))) {
-        Object.assign(x.schemas, y.schemas);
+    OpenApiEndpointComparator.hashCode = hashCode;
+    function equals(x, y) {
+        return x.path === y.path && x.method === y.method;
     }
-    return x;
-}
+    OpenApiEndpointComparator.equals = equals;
+    function compare(x, y) {
+        if (x.path !== y.path) return x.path.localeCompare(y.path);
+        return x.method.localeCompare(y.method);
+    }
+    OpenApiEndpointComparator.compare = compare;
+})(OpenApiEndpointComparator || (OpenApiEndpointComparator = {}));
 
-async function divideAndConquer$1(ctx, operations, typeNames, retry, progress) {
-    const remained = new Set(typeNames);
-    const components = {
-        schemas: {}
+async function orchestrateInterfaceEndpoints(ctx, groups, content = `Make endpoints for the given assets`) {
+    const progress = {
+        total: groups.length,
+        completed: 0
     };
-    for (let i = 0; i < retry; ++i) {
-        if (remained.size === 0) break;
-        const before = remained.size;
-        const newbie = await forceRetry((() => process$5(ctx, operations, components, remained)));
-        for (const key of Object.keys(newbie.schemas)) {
-            components.schemas[key] = newbie.schemas[key];
-            remained.delete(key);
-        }
-        if (before - remained.size !== 0) progress(before - remained.size);
-    }
-    return components;
+    const endpoints = (await Promise.all(groups.map((g => process$6(ctx, g, content, progress))))).flat();
+    return new HashSet(endpoints, OpenApiEndpointComparator.hashCode, OpenApiEndpointComparator.equals).toJSON();
 }
 
-async function process$5(ctx, operations, oldbie, remained) {
+async function process$6(ctx, group, content, progress) {
+    const start = new Date;
     const pointer = {
         value: null
     };
@@ -1850,148 +1758,132 @@ async function process$5(ctx, operations, oldbie, remained) {
                 describe: null
             }
         },
-        histories: [ ...transformInterfaceHistories(ctx.state(), '# AutoAPI Schema Agent System Prompt\n\nYou are AutoAPI Schema Agent, an expert in creating comprehensive schema components for OpenAPI specifications in the `AutoBeOpenApi.IDocument` format. Your specialized role focuses on the third phase of a multi-agent orchestration process for large-scale API design.\n\nYour mission is to analyze the provided API operations, paths, methods, Prisma schema files, and ERD diagrams to construct a complete and consistent set of component schemas that accurately represent all entities and their relationships in the system.\n\n## 1. Context and Your Role in the Multi-Agent Process\n\nYou are the third agent in a three-phase process:\n1. **Phase 1** (completed): Analysis of requirements, Prisma schema, and ERD to define API paths and methods\n2. **Phase 2** (completed): Creation of detailed API operations based on the defined paths and methods\n3. **Phase 3** (your role): Construction of comprehensive component schemas for all entities\n\nYou will receive:\n- The complete list of API operations from Phase 2\n- The original Prisma schema with detailed comments\n- ERD diagrams in Mermaid format\n- Requirement analysis documents\n\n## 2. Primary Responsibilities\n\nYour specific tasks are:\n\n1. **Extract All Entity Types**: Analyze all API operations and identify every distinct entity type referenced\n2. **Define Complete Schema Components**: Create detailed schema definitions for every entity and its variants\n3. **Maintain Type Naming Conventions**: Follow the established type naming patterns\n4. **Ensure Schema Completeness**: Verify that ALL entities in the Prisma schema have corresponding component schemas\n5. **Create Type Variants**: Define all necessary type variants for each entity (.ICreate, .IUpdate, .ISummary, etc.)\n6. **Document Thoroughly**: Provide comprehensive descriptions for all schema components\n7. **Validate Consistency**: Ensure schema definitions align with API operations\n8. **Use Named References Only**: NEVER use inline/anonymous object definitions - ALL object types must be defined as named types in the components.schemas section and referenced using $ref\n\n## 3. Schema Design Principles\n\n### 3.1. Type Naming Conventions\n\n- **Main Entity Types**: Use `IEntityName` format\n- **Operation-Specific Types**:\n  - `IEntityName.ICreate`: Request body for creation operations (POST)\n  - `IEntityName.IUpdate`: Request body for update operations (PUT or PATCH)\n  - `IEntityName.ISummary`: Simplified response version with essential properties\n  - `IEntityName.IRequest`: Request parameters for list operations (search/filter/pagination)\n  - `IEntityName.IAbridge`: Intermediate view with more detail than Summary but less than full entity\n  - `IEntityName.IInvert`: Alternative representation of an entity from a different perspective\n- **Container Types**: \n  - `IPageIEntityName`: Paginated results container (use the standard IPage structure)\n\n### 3.2. Schema Definition Requirements\n\n- **Completeness**: Include ALL properties from the Prisma schema for each entity\n- **Type Accuracy**: Map Prisma types to appropriate OpenAPI types and formats\n- **Required Fields**: Accurately mark required fields based on Prisma schema constraints\n- **Relationships**: Properly handle entity relationships (references to other entities)\n- **Enumerations**: Define all enum types referenced in entity schemas\n- **Detailed Documentation**: \n  - Schema descriptions must reference related Prisma schema table comments\n  - Property descriptions must reference related Prisma schema column comments\n  - All descriptions must be organized in multiple paragraphs for better readability\n- **Named References Only**: \n  - Every object type MUST be defined as a named type in the components.schemas section\n  - NEVER use inline/anonymous object definitions anywhere in the schema\n  - All property types that are objects must use $ref to reference a named type\n  - This applies to EVERY object in the schema, including nested objects and arrays of objects\n\n### 3.3. 🔴 CRITICAL Security Requirements\n\n#### Response Types - NEVER expose sensitive fields:\n- **Password fields**: NEVER include fields like `password`, `hashed_password`, `encrypted_password`, `salt`, etc. in ANY response type\n- **Security tokens**: NEVER expose `refresh_token`, `api_key`, `secret_key`, or similar security credentials\n- **Internal system fields**: Avoid exposing internal implementation details like `password_reset_token`, `email_verification_code`\n- **Sensitive personal data**: Be cautious with fields containing sensitive information based on your domain\n\n**Example of FORBIDDEN response properties**:\n```typescript\n// ❌ NEVER include these in response types\ninterface IUser {\n  id: string;\n  email: string;\n  hashed_password: string;  // FORBIDDEN\n  salt: string;             // FORBIDDEN\n  refresh_token: string;    // FORBIDDEN\n  api_secret: string;       // FORBIDDEN\n}\n\n// ✅ Correct response type\ninterface IUser {\n  id: string;\n  email: string;\n  name: string;\n  created_at: string;\n  // Password and security fields are intentionally omitted\n}\n```\n\n#### Request Types - NEVER accept actor IDs directly:\n- **Actor identification**: NEVER accept fields like `user_id`, `member_id`, `creator_id`, `author_id` in request bodies\n- **Authentication source**: The authenticated user\'s identity comes from the authentication decorator, NOT from request body\n- **Security principle**: Clients should NEVER be able to specify "who they are" - this must come from verified authentication\n\n**Example of FORBIDDEN request properties**:\n```typescript\n// ❌ NEVER accept actor IDs in request types\ninterface IPostCreate {\n  title: string;\n  content: string;\n  author_id: string;      // FORBIDDEN - comes from authentication\n  created_by: string;     // FORBIDDEN - comes from authentication\n}\n\n// ✅ Correct request type\ninterface IPostCreate {\n  title: string;\n  content: string;\n  category_id: string;    // OK - selecting a category\n  // author_id will be set by the server using authenticated user info\n}\n```\n\n**Why this matters**:\n1. **Security**: Prevents users from impersonating others or claiming false ownership\n2. **Data integrity**: Ensures the true actor is recorded for audit trails\n3. **Authorization**: Enables proper ownership verification in provider functions\n\n**Remember**: The authenticated user information is provided by the decorator at the controller level and passed to the provider function - it should NEVER come from client input.\n\n### 3.3. Standard Type Definitions\n\nFor paginated results, use the standard `IPage<T>` interface:\n\n```typescript\n/**\n * A page.\n *\n * Collection of records with pagination information.\n *\n * @author Samchon\n */\nexport interface IPage<T extends object> {\n  /**\n   * Page information.\n   */\n  pagination: IPage.IPagination;\n\n  /**\n   * List of records.\n   */\n  data: T[];\n}\nexport namespace IPage {\n  /**\n   * Page information.\n   */\n  export interface IPagination {\n    /**\n     * Current page number.\n     */\n    current: number & tags.Type<"uint32">;\n\n    /**\n     * Limitation of records per a page.\n     *\n     * @default 100\n     */\n    limit: number & tags.Type<"uint32">;\n\n    /**\n     * Total records in the database.\n     */\n    records: number & tags.Type<"uint32">;\n\n    /**\n     * Total pages.\n     *\n     * Equal to {@link records} / {@link limit} with ceiling.\n     */\n    pages: number & tags.Type<"uint32">;\n  }\n\n  /**\n   * Page request data\n   */\n  export interface IRequest {\n    /**\n     * Page number.\n     */\n    page?: null | (number & tags.Type<"uint32">);\n\n    /**\n     * Limitation of records per a page.\n     *\n     * @default 100\n     */\n    limit?: null | (number & tags.Type<"uint32">);\n  }\n}\n```\n\n## 4. Implementation Strategy\n\n### 4.1. Comprehensive Entity Identification\n\n1. **Extract All Entity References**:\n   - Analyze all API operation paths for entity identifiers\n   - Examine request and response bodies in API operations\n   - Review the Prisma schema to identify ALL entities\n\n2. **Create Entity Tracking System**:\n   - List ALL entities from the Prisma schema\n   - Cross-reference with entities mentioned in API operations\n   - Identify any entities that might be missing schema definitions\n\n### 4.2. Schema Definition Process\n\n1. **For Each Entity**:\n   - Define the main entity schema (`IEntityName`)\n   - Create all necessary variant types based on API operations\n   - Ensure all properties are documented with descriptions from Prisma schema\n   - Mark required fields based on Prisma schema constraints\n   - **CRITICAL**: Apply security filtering - remove sensitive fields from response types\n\n2. **For Relationship Handling**:\n   - Identify all relationships from the ERD and Prisma schema\n   - Define appropriate property types for relationships (IDs, nested objects, arrays)\n   - Document relationship constraints and cardinality\n   - **IMPORTANT**: For "belongs to" relationships, never accept the owner ID in requests\n\n3. **For Variant Types**:\n   - Create `.ICreate` types with appropriate required/optional fields for creation\n     - **NEVER include**: creator_id, author_id, user_id, created_by fields\n     - These fields will be populated from authenticated user context\n   - Define `.IUpdate` types with all fields made optional for updates\n     - **NEVER include**: updater_id, modified_by, last_updated_by fields\n     - **NEVER allow**: changing ownership fields like author_id or creator_id\n   - Build `.ISummary` types with essential fields for list views\n     - Include only safe, public-facing properties\n   - Define `.IRequest` types with search/filter/sort parameters\n     - May include filters like "my_posts_only" but not "user_id" parameters\n\n4. **Security Checklist for Each Type**:\n   - ✓ No password or hash fields in any response type\n   - ✓ No security tokens or keys in any response type\n   - ✓ No actor ID fields in any request type\n   - ✓ No internal system fields exposed in responses\n   - ✓ Ownership fields are read-only (never in request types)\n\n### 4.3. Schema Completeness Verification\n\n1. **Entity Coverage Check**:\n   - Verify every entity in the Prisma schema has at least one schema definition\n   - Check that all entities referenced in API operations have schema definitions\n\n2. **Property Coverage Check**:\n   - Ensure all properties from the Prisma schema are included in entity schemas\n   - Verify property types align with Prisma schema definitions\n\n3. **Variant Type Verification**:\n   - Confirm necessary variant types exist based on API operations\n   - Ensure variant types have appropriate property subsets and constraints\n\n## 5. Documentation Quality Requirements\n\n### 5.1. **Schema Type Descriptions**\n- Must reference related Prisma schema table description comments\n- Must be extremely detailed and comprehensive\n- Must be organized in multiple paragraphs\n- Should explain the entity\'s role in the business domain\n- Should describe relationships with other entities\n\n### 5.2. **Property Descriptions**\n- Must reference related Prisma schema column description comments\n- Must explain the purpose, constraints, and format of each property\n- Should note business rules that apply to the property\n- Should provide examples when helpful\n- Should use multiple paragraphs for complex properties\n\n## 6. Output Format\n\nYour output should be the complete `components` section of the OpenAPI document:\n\n```typescript\nconst components: OpenApi.IComponents = {\n  schemas: {\n    // Main entity types\n    IEntityName: { \n      type: "object", \n      properties: {\n        propertyName: {\n          type: "string",\n          description: "Detailed property description referencing Prisma schema column comments.\\n\\nMultiple paragraphs where appropriate."\n        }\n        // ...more properties\n        // SECURITY: Never include password, hashed_password, salt, or other sensitive fields in response types\n      },\n      required: [...],\n      description: "Extremely detailed explanation about IEntityName referencing Prisma schema table comments.\\n\\nMultiple paragraphs focusing on different aspects of the entity.",\n    },\n    // Variant types\n    "IEntityName.ICreate": { \n      // SECURITY: Never include author_id, creator_id, user_id - these come from authentication context\n      ... \n    },\n    "IEntityName.IUpdate": { \n      // SECURITY: Never allow updating ownership fields like author_id or creator_id\n      ... \n    },\n    "IEntityName.ISummary": { ... },\n    "IEntityName.IRequest": { ... },\n    \n    // Repeat for ALL entities\n    \n    // Standard types\n    "IPage": { ... },\n    "IPage.IPagination": { ... },\n    "IPage.IRequest": { ... },\n    \n    // Enumerations\n    "EEnumName": { ... }\n  }\n}\n```\n\n## 7. Critical Success Factors\n\n### 7.1. Absolute Completeness Principles\n\n- **Process ALL Entities**: EVERY entity defined in the Prisma schema MUST have corresponding schema components.\n- **Complete Property Coverage**: ALL properties of each entity MUST be included in schema definitions.\n- **Variant Type Comprehensiveness**: ALL necessary variant types MUST be defined based on API operations.\n- **No Simplification**: Complex entities or relationships MUST be faithfully represented without simplification.\n- **Verification of Completeness**: Before final output, verify that ALL entities and properties have been defined.\n\n### 7.2. High-Volume Processing Strategy\n\n- **Batch Processing**: If there are many entities, process them in groups, but ALL groups MUST be completed.\n- **No Prioritization**: ALL entities and their properties have equal importance and must be processed.\n- **Systematic Approach**: Use a methodical approach to ensure no entity or property is overlooked.\n- **Detailed Tracking**: Maintain a tracking system to verify completeness of schema definitions.\n\n### 7.3. Critical Warnings\n\n- **Partial Implementation Prohibited**: "Defining schemas for only some entities and omitting others" is a CRITICAL ERROR.\n- **Property Omission Prohibited**: "Including only some properties of an entity" is a SERIOUS ERROR.\n- **No Simplification**: "Simplifying complex entities or relationships" is NOT ACCEPTABLE.\n- **Ignore Capacity Limitations**: Processing only some entities due to their quantity is a SERIOUS ERROR.\n- **Named Types Required**: Using inline/anonymous object definitions instead of named type references ($ref) is a CRITICAL ERROR. EVERY object type must be defined in the components.schemas section and referenced by name.\n- **Security Violations**: Including password fields in responses or actor IDs in requests is a CRITICAL SECURITY ERROR.\n- **Authentication Bypass**: Accepting user identity from request body instead of authentication context is a CRITICAL SECURITY ERROR.\n\n## 8. Execution Process\n\n1. **Initialization**:\n   - Analyze all input data (API operations, Prisma schema, ERD)\n   - Create a complete inventory of entities and their relationships\n\n2. **Schema Development**:\n   - Systematically define schema components for each entity and its variants\n   - Document all components and properties thoroughly\n\n3. **Verification**:\n   - Validate completeness against the Prisma schema\n   - Verify consistency with API operations\n   - Ensure all relationships are properly handled\n\n4. **Output Generation**:\n   - Produce the complete `components` section in the required format\n   - Verify the output meets all quality and completeness requirements\n\nRemember that your role is CRITICAL to the success of the entire API design process. The schemas you define will be the foundation for ALL data exchange in the API. Thoroughness, accuracy, and completeness are your highest priorities.\n\n## 9. Integration with Previous Phases\n\n- Ensure your schema components align perfectly with the API operations defined in Phase 2\n- Reference the same entities and property names used in the API paths from Phase 1\n- Maintain consistency in naming, typing, and structure throughout the entire API design\n\n## 10. Final Output Format\n\nYour final output should be the complete `components` section that can be directly integrated with the API operations from Phase 2 to form a complete `AutoBeOpenApi.IDocument` object.\n\nAlways aim to create schema components that are intuitive, well-documented, and accurately represent the business domain. Your schema definitions should meet ALL business requirements while being extensible and maintainable. Remember to define components for EVERY SINGLE independent entity table in the Prisma schema. NO ENTITY OR PROPERTY SHOULD BE OMITTED FOR ANY REASON.'), {
-            id: v4(),
-            created_at: (new Date).toISOString(),
-            type: "assistantMessage",
-            text: [ "Here is the OpenAPI operations generated by phase 2.", "", "```json", JSON.stringify(operations), "```" ].join("\n")
-        } ],
-        controllers: [ createApplication$b({
+        histories: transformInterfaceEndpointHistories(ctx.state(), group),
+        controllers: [ createApplication$c({
             model: ctx.model,
-            build: async components => {
-                pointer.value ?? (pointer.value = {
-                    schemas: {}
-                });
-                Object.assign(pointer.value.schemas, components.schemas);
-            },
-            pointer
+            build: endpoints => {
+                pointer.value ?? (pointer.value = endpoints);
+                pointer.value.push(...endpoints);
+            }
         }) ]
     });
     enforceToolCall(agentica);
-    const already = Object.keys(oldbie.schemas);
-    await agentica.conversate([ "Make type components please.", "", "Here is the list of request/response bodies' type names from", "OpenAPI operations. Make type components of them. If more object", "types are required during making the components, please make them", "too.", "", ...Array.from(remained).map((k => `- \`${k}\``)), ...already.length !== 0 ? [ "", "> By the way, here is the list of components schemas what you've", "> already made. So, you don't need to make them again.", ">", ...already.map((k => `> - \`${k}\``)) ] : [] ].join("\n")).finally((() => {
+    await agentica.conversate(content).finally((() => {
         const tokenUsage = agentica.getTokenUsage();
         ctx.usage().record(tokenUsage, [ "interface" ]);
     }));
-    if (pointer.value === null) {
-        throw new Error("Failed to create components.");
-    }
-    return OpenApiV3_1Emender.convertComponents(pointer.value);
+    if (pointer.value === null) throw new Error("Failed to generate endpoints.");
+    const event = {
+        type: "interfaceEndpoints",
+        endpoints: new HashSet(pointer.value, OpenApiEndpointComparator.hashCode, OpenApiEndpointComparator.equals).toJSON(),
+        created_at: start.toISOString(),
+        step: ctx.state().analyze?.step ?? 0,
+        completed: ++progress.completed,
+        total: progress.total
+    };
+    ctx.dispatch(event);
+    return pointer.value;
 }
 
-function createApplication$b(props) {
+function createApplication$c(props) {
     assertSchemaModel(props.model);
-    const application = collection$c[props.model];
+    const application = collection$d[props.model];
     return {
         protocol: "class",
         name: "interface",
         application,
         execute: {
-            makeComponents: async next => {
-                await props.build(next.components);
+            makeEndpoints: next => {
+                props.build(next.endpoints);
             }
         }
     };
 }
 
-const claude$c = {
+const claude$d = {
     model: "claude",
     options: {
         reference: true,
         separate: null
     },
     functions: [ {
-        name: "makeComponents",
+        name: "makeEndpoints",
         parameters: {
-            description: " Properties containing components to generate.\n\n------------------------------\n\nCurrent Type: {@link IMakeComponentsProps}",
+            description: " Properties containing the endpoints\n\n------------------------------\n\nCurrent Type: {@link IAutoBeInterfaceEndpointApplication.IProps}",
             type: "object",
             properties: {
-                components: {
-                    description: 'Complete set of schema components for the OpenAPI specification.\n\nThis property contains comprehensive type definitions for all entities in\nthe system. It is the central repository of all named schema types that\nwill be used throughout the API specification.\n\nCRITICAL REQUIREMENT: All object types MUST be defined as named types in\nthe components.schemas section. Inline anonymous object definitions are\nstrictly prohibited.\n\nThis components object should include:\n\n- Main entity types (IEntityName)\n- Operation-specific variants (.ICreate, .IUpdate, .ISummary, etc.)\n- Container types (IPage<T> for pagination)\n- Enumeration types\n\nAll schema definitions must include detailed descriptions that reference\nthe original Prisma schema comments and thoroughly document each property.\nEvery property that references an object must use a $ref to a named type in\nthe components.schemas section. This applies to all objects in request\nbodies, response bodies, and properties that are objects or arrays of\nobjects.\n\nExample structure:\n\n```typescript\n{\n  components: {\n    schemas: {\n      IUser: {\n        type: "object",\n        properties: {\n          id: { type: "string", format: "uuid" },\n          email: { type: "string", format: "email" },\n          profile: { "$ref": "#/components/schemas/IUserProfile" }\n        },\n        required: ["id", "email"],\n        description: "User entity representing system account holders..."\n      },\n      "IUser.ICreate": { ... },\n      // Additional schemas\n    }\n  }\n}\n```',
-                    $ref: "#/$defs/OmitAutoBeOpenApi.IComponentsauthorization"
+                endpoints: {
+                    description: "The endpoints to generate.",
+                    type: "array",
+                    items: {
+                        $ref: "#/$defs/AutoBeOpenApi.IEndpoint"
+                    }
                 }
             },
-            required: [ "components" ],
+            required: [ "endpoints" ],
             additionalProperties: false,
             $defs: {
-                "OmitAutoBeOpenApi.IComponentsauthorization": {
-                    description: "Construct a type with the properties of T except for those in type K.",
-                    type: "object",
-                    properties: {
-                        schemas: {
-                            description: "An object to hold reusable DTO schemas.\n\nIn other words, a collection of named JSON schemas.\n\nIMPORTANT: For each schema in this collection:\n\n1. EVERY schema MUST have a detailed description that references and aligns\n   with the description comments from the corresponding Prisma DB schema\n   tables\n2. EACH property within the schema MUST have detailed descriptions that\n   reference and align with the description comments from the\n   corresponding DB schema columns\n3. All descriptions MUST be organized into MULTIPLE PARAGRAPHS (separated by\n   line breaks) when appropriate\n4. Descriptions should be comprehensive enough that anyone reading them can\n   understand the purpose, functionality, and constraints of each type\n   and property without needing to reference other documentation",
-                            $ref: "#/$defs/RecordstringAutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema"
-                        }
-                    },
-                    required: [ "schemas" ]
-                },
-                "RecordstringAutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema": {
-                    description: "Construct a type with a set of properties K of type T",
-                    type: "object",
-                    properties: {},
-                    required: [],
-                    additionalProperties: {
-                        $ref: "#/$defs/AutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema"
-                    }
-                },
-                "AutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema": {
-                    description: "Descriptive type schema info.\n\n`AutoBeOpenApi.IJsonSchemaDescriptive` is a type schema info of the OpenAPI\nGenerative, but it has a `description` property which is required.\n\n`AutoBeOpenApi.IJsonSchemaDescriptive` basically follows the JSON schema\nspecification of OpenAPI v3.1, but a little bit shrunk to remove ambiguous\nand duplicated expressions of OpenAPI v3.1 for the convenience, clarity,\nand AI generation.\n\nCRITICAL INSTRUCTIONS FOR OPTIMAL AI GENERATION:\n\nWhen creating descriptions for components, types, and properties:\n\n1. ALWAYS refer to and incorporate the description comments from the\n   corresponding Prisma DB schema tables and columns. The descriptions\n   should match the style, level of detail, and terminology used in the\n   Prisma schema.\n2. ALL descriptions MUST be organized into MULTIPLE PARAGRAPHS separated by\n   line breaks. Single-paragraph descriptions should be avoided.\n3. Descriptions should comprehensively cover:\n\n   - The purpose and business meaning of the type or property\n   - Relationships to other entities\n   - Validation rules, constraints, and edge cases\n   - Usage context and examples when helpful\n4. For each property of an object type, ensure its description reflects the\n   corresponding column description in the Prisma DB schema, maintaining\n   the same level of detail and terminology\n5. Descriptions should be so detailed and clear that anyone reading them can\n   fully understand the type or property without needing to reference any\n   other documentation",
+                "AutoBeOpenApi.IEndpoint": {
+                    description: "API endpoint information.",
                     type: "object",
                     properties: {
-                        description: {
-                            description: "Description about the type.\n\nCRITICAL: This description MUST be extensively detailed and MUST\nreference and align with the description comments from the\ncorresponding Prisma DB schema tables and columns.\n\nThe description MUST be organized into MULTIPLE PARAGRAPHS (separated\nby line breaks) based on different aspects of the type:\n\n- The purpose and business meaning of the type\n- Relationships to other entities in the system\n- Validation rules, constraints, and edge cases\n- Usage context and examples when helpful\n\nThis structured approach improves readability and helps readers better\nunderstand the type's various characteristics and use cases. The\ndescription should be so comprehensive that anyone reading it can fully\nunderstand the type without needing to reference other documentation.\n\n> MUST be written in English. Never use other languages.",
-                            type: "string"
+                        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\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: [ "description" ]
+                    required: [ "path", "method" ]
                 }
             }
         },
-        description: "Generate OpenAPI components containing named schema types.\n\nThis method receives a complete set of schema components and integrates\nthem into the final OpenAPI specification. It processes all entity schemas,\ntheir variants, and related type definitions to ensure a comprehensive and\nconsistent API design.\n\nThe provided components should include schemas for all entities identified\nin the previous phases of API path/method definition and operation\ncreation. This ensures that the final OpenAPI document has complete type\ncoverage for all operations.\n\nCRITICAL: All schema definitions must follow the established naming\nconventions (IEntityName, IEntityName.ICreate, etc.) and must be thoroughly\ndocumented with descriptions that reference the original Prisma schema\ncomments.",
+        description: "Create Restful API endpoints.\n\nCreate Restful API endpoints referencing the given documents; requirement\nanalysis documents, and Prisma schema files with ERD descriptions. The API\nendpoints must cover every requirements and every entities in the ERD.\n\nAlso, each combination of {@link AutoBeOpenApi.IEndpoint.path} and\n{@link AutoBeOpenApi.IEndpoint.method} must be unique to avoid duplicates.\nPlease don't make any duplicates.",
         validate: (() => {
-            const _io0 = input => "object" === typeof input.components && null !== input.components && _io1(input.components);
-            const _io1 = input => "object" === typeof input.schemas && null !== input.schemas && false === Array.isArray(input.schemas) && _io2(input.schemas);
-            const _io2 = input => Object.keys(input).every((key => {
-                const value = input[key];
-                if (undefined === value) return true;
-                return "object" === typeof value && null !== value && _io3(value);
-            }));
-            const _io3 = input => "string" === typeof input.description;
-            const _vo0 = (input, _path, _exceptionable = true) => [ ("object" === typeof input.components && null !== input.components || _report(_exceptionable, {
-                path: _path + ".components",
-                expected: 'Omit<AutoBeOpenApi.IComponents, "authorization">',
-                value: input.components
-            })) && _vo1(input.components, _path + ".components", _exceptionable) || _report(_exceptionable, {
-                path: _path + ".components",
-                expected: 'Omit<AutoBeOpenApi.IComponents, "authorization">',
-                value: input.components
-            }) ].every((flag => flag));
-            const _vo1 = (input, _path, _exceptionable = true) => [ ("object" === typeof input.schemas && null !== input.schemas && false === Array.isArray(input.schemas) || _report(_exceptionable, {
-                path: _path + ".schemas",
-                expected: "Record<string, AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>>",
-                value: input.schemas
-            })) && _vo2(input.schemas, _path + ".schemas", _exceptionable) || _report(_exceptionable, {
-                path: _path + ".schemas",
-                expected: "Record<string, AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>>",
-                value: input.schemas
+            const _io0 = input => Array.isArray(input.endpoints) && input.endpoints.every((elem => "object" === typeof elem && null !== elem && _io1(elem)));
+            const _io1 = 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 _vo0 = (input, _path, _exceptionable = true) => [ (Array.isArray(input.endpoints) || _report(_exceptionable, {
+                path: _path + ".endpoints",
+                expected: "Array<AutoBeOpenApi.IEndpoint>",
+                value: input.endpoints
+            })) && input.endpoints.map(((elem, _index2) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                path: _path + ".endpoints[" + _index2 + "]",
+                expected: "AutoBeOpenApi.IEndpoint",
+                value: elem
+            })) && _vo1(elem, _path + ".endpoints[" + _index2 + "]", _exceptionable) || _report(_exceptionable, {
+                path: _path + ".endpoints[" + _index2 + "]",
+                expected: "AutoBeOpenApi.IEndpoint",
+                value: elem
+            }))).every((flag => flag)) || _report(_exceptionable, {
+                path: _path + ".endpoints",
+                expected: "Array<AutoBeOpenApi.IEndpoint>",
+                value: input.endpoints
             }) ].every((flag => flag));
-            const _vo2 = (input, _path, _exceptionable = true) => [ false === _exceptionable || Object.keys(input).map((key => {
-                const value = input[key];
-                if (undefined === value) return true;
-                return ("object" === typeof value && null !== value || _report(_exceptionable, {
-                    path: _path + __typia_transform__accessExpressionAsString._accessExpressionAsString(key),
-                    expected: "AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>",
-                    value
-                })) && _vo3(value, _path + __typia_transform__accessExpressionAsString._accessExpressionAsString(key), _exceptionable) || _report(_exceptionable, {
-                    path: _path + __typia_transform__accessExpressionAsString._accessExpressionAsString(key),
-                    expected: "AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>",
-                    value
-                });
-            })).every((flag => flag)) ].every((flag => flag));
-            const _vo3 = (input, _path, _exceptionable = true) => [ "string" === typeof input.description || _report(_exceptionable, {
-                path: _path + ".description",
-                expected: "string",
-                value: input.description
+            const _vo1 = (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 __is = input => "object" === typeof input && null !== input && _io0(input);
             let errors;
@@ -2002,11 +1894,11 @@ const claude$c = {
                     _report = __typia_transform__validateReport._validateReport(errors);
                     ((input, _path, _exceptionable = true) => ("object" === typeof input && null !== input || _report(true, {
                         path: _path + "",
-                        expected: "IMakeComponentsProps",
+                        expected: "IAutoBeInterfaceEndpointApplication.IProps",
                         value: input
                     })) && _vo0(input, _path + "", true) || _report(true, {
                         path: _path + "",
-                        expected: "IMakeComponentsProps",
+                        expected: "IAutoBeInterfaceEndpointApplication.IProps",
                         value: input
                     }))(input, "$input", true);
                     const success = 0 === errors.length;
@@ -2028,7 +1920,7 @@ const claude$c = {
     } ]
 };
 
-const collection$c = {
+const collection$d = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -2037,95 +1929,73 @@ const collection$c = {
             separate: null
         },
         functions: [ {
-            name: "makeComponents",
+            name: "makeEndpoints",
             parameters: {
-                description: ' Properties containing components to generate.\n\n------------------------------\n\nCurrent Type: {@link IMakeComponentsProps}\n\n### Description of {@link components} property:\n\n> Complete set of schema components for the OpenAPI specification.\n> \n> This property contains comprehensive type definitions for all entities in\n> the system. It is the central repository of all named schema types that\n> will be used throughout the API specification.\n> \n> CRITICAL REQUIREMENT: All object types MUST be defined as named types in\n> the components.schemas section. Inline anonymous object definitions are\n> strictly prohibited.\n> \n> This components object should include:\n> \n> - Main entity types (IEntityName)\n> - Operation-specific variants (.ICreate, .IUpdate, .ISummary, etc.)\n> - Container types (IPage<T> for pagination)\n> - Enumeration types\n> \n> All schema definitions must include detailed descriptions that reference\n> the original Prisma schema comments and thoroughly document each property.\n> Every property that references an object must use a $ref to a named type in\n> the components.schemas section. This applies to all objects in request\n> bodies, response bodies, and properties that are objects or arrays of\n> objects.\n> \n> Example structure:\n> \n> ```typescript\n> {\n>   components: {\n>     schemas: {\n>       IUser: {\n>         type: "object",\n>         properties: {\n>           id: { type: "string", format: "uuid" },\n>           email: { type: "string", format: "email" },\n>           profile: { "$ref": "#/components/schemas/IUserProfile" }\n>         },\n>         required: ["id", "email"],\n>         description: "User entity representing system account holders..."\n>       },\n>       "IUser.ICreate": { ... },\n>       // Additional schemas\n>     }\n>   }\n> }\n> ```',
+                description: " Properties containing the endpoints\n\n------------------------------\n\nCurrent Type: {@link IAutoBeInterfaceEndpointApplication.IProps}",
                 type: "object",
                 properties: {
-                    components: {
-                        $ref: "#/$defs/OmitAutoBeOpenApi.IComponentsauthorization"
+                    endpoints: {
+                        description: "The endpoints to generate.",
+                        type: "array",
+                        items: {
+                            $ref: "#/$defs/AutoBeOpenApi.IEndpoint"
+                        }
                     }
                 },
-                required: [ "components" ],
+                required: [ "endpoints" ],
                 additionalProperties: false,
                 $defs: {
-                    "OmitAutoBeOpenApi.IComponentsauthorization": {
-                        description: "Construct a type with the properties of T except for those in type K.\n\n### Description of {@link schemas} property:\n\n> An object to hold reusable DTO schemas.\n> \n> In other words, a collection of named JSON schemas.\n> \n> IMPORTANT: For each schema in this collection:\n> \n> 1. EVERY schema MUST have a detailed description that references and aligns\n>    with the description comments from the corresponding Prisma DB schema\n>    tables\n> 2. EACH property within the schema MUST have detailed descriptions that\n>    reference and align with the description comments from the\n>    corresponding DB schema columns\n> 3. All descriptions MUST be organized into MULTIPLE PARAGRAPHS (separated by\n>    line breaks) when appropriate\n> 4. Descriptions should be comprehensive enough that anyone reading them can\n>    understand the purpose, functionality, and constraints of each type\n>    and property without needing to reference other documentation",
-                        type: "object",
-                        properties: {
-                            schemas: {
-                                $ref: "#/$defs/RecordstringAutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema"
-                            }
-                        },
-                        required: [ "schemas" ]
-                    },
-                    "RecordstringAutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema": {
-                        description: "Construct a type with a set of properties K of type T",
-                        type: "object",
-                        properties: {},
-                        required: [],
-                        additionalProperties: {
-                            $ref: "#/$defs/AutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema"
-                        }
-                    },
-                    "AutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema": {
-                        description: "Descriptive type schema info.\n\n`AutoBeOpenApi.IJsonSchemaDescriptive` is a type schema info of the OpenAPI\nGenerative, but it has a `description` property which is required.\n\n`AutoBeOpenApi.IJsonSchemaDescriptive` basically follows the JSON schema\nspecification of OpenAPI v3.1, but a little bit shrunk to remove ambiguous\nand duplicated expressions of OpenAPI v3.1 for the convenience, clarity,\nand AI generation.\n\nCRITICAL INSTRUCTIONS FOR OPTIMAL AI GENERATION:\n\nWhen creating descriptions for components, types, and properties:\n\n1. ALWAYS refer to and incorporate the description comments from the\n   corresponding Prisma DB schema tables and columns. The descriptions\n   should match the style, level of detail, and terminology used in the\n   Prisma schema.\n2. ALL descriptions MUST be organized into MULTIPLE PARAGRAPHS separated by\n   line breaks. Single-paragraph descriptions should be avoided.\n3. Descriptions should comprehensively cover:\n\n   - The purpose and business meaning of the type or property\n   - Relationships to other entities\n   - Validation rules, constraints, and edge cases\n   - Usage context and examples when helpful\n4. For each property of an object type, ensure its description reflects the\n   corresponding column description in the Prisma DB schema, maintaining\n   the same level of detail and terminology\n5. Descriptions should be so detailed and clear that anyone reading them can\n   fully understand the type or property without needing to reference any\n   other documentation",
+                    "AutoBeOpenApi.IEndpoint": {
+                        description: "API endpoint information.",
                         type: "object",
                         properties: {
-                            description: {
-                                description: "Description about the type.\n\nCRITICAL: This description MUST be extensively detailed and MUST\nreference and align with the description comments from the\ncorresponding Prisma DB schema tables and columns.\n\nThe description MUST be organized into MULTIPLE PARAGRAPHS (separated\nby line breaks) based on different aspects of the type:\n\n- The purpose and business meaning of the type\n- Relationships to other entities in the system\n- Validation rules, constraints, and edge cases\n- Usage context and examples when helpful\n\nThis structured approach improves readability and helps readers better\nunderstand the type's various characteristics and use cases. The\ndescription should be so comprehensive that anyone reading it can fully\nunderstand the type without needing to reference other documentation.\n\n> MUST be written in English. Never use other languages.",
+                            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\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: [ "description" ]
+                        required: [ "path", "method" ]
                     }
                 }
             },
-            description: "Generate OpenAPI components containing named schema types.\n\nThis method receives a complete set of schema components and integrates\nthem into the final OpenAPI specification. It processes all entity schemas,\ntheir variants, and related type definitions to ensure a comprehensive and\nconsistent API design.\n\nThe provided components should include schemas for all entities identified\nin the previous phases of API path/method definition and operation\ncreation. This ensures that the final OpenAPI document has complete type\ncoverage for all operations.\n\nCRITICAL: All schema definitions must follow the established naming\nconventions (IEntityName, IEntityName.ICreate, etc.) and must be thoroughly\ndocumented with descriptions that reference the original Prisma schema\ncomments.",
+            description: "Create Restful API endpoints.\n\nCreate Restful API endpoints referencing the given documents; requirement\nanalysis documents, and Prisma schema files with ERD descriptions. The API\nendpoints must cover every requirements and every entities in the ERD.\n\nAlso, each combination of {@link AutoBeOpenApi.IEndpoint.path} and\n{@link AutoBeOpenApi.IEndpoint.method} must be unique to avoid duplicates.\nPlease don't make any duplicates.",
             validate: (() => {
-                const _io0 = input => "object" === typeof input.components && null !== input.components && _io1(input.components);
-                const _io1 = input => "object" === typeof input.schemas && null !== input.schemas && false === Array.isArray(input.schemas) && _io2(input.schemas);
-                const _io2 = input => Object.keys(input).every((key => {
-                    const value = input[key];
-                    if (undefined === value) return true;
-                    return "object" === typeof value && null !== value && _io3(value);
-                }));
-                const _io3 = input => "string" === typeof input.description;
-                const _vo0 = (input, _path, _exceptionable = true) => [ ("object" === typeof input.components && null !== input.components || _report(_exceptionable, {
-                    path: _path + ".components",
-                    expected: 'Omit<AutoBeOpenApi.IComponents, "authorization">',
-                    value: input.components
-                })) && _vo1(input.components, _path + ".components", _exceptionable) || _report(_exceptionable, {
-                    path: _path + ".components",
-                    expected: 'Omit<AutoBeOpenApi.IComponents, "authorization">',
-                    value: input.components
-                }) ].every((flag => flag));
-                const _vo1 = (input, _path, _exceptionable = true) => [ ("object" === typeof input.schemas && null !== input.schemas && false === Array.isArray(input.schemas) || _report(_exceptionable, {
-                    path: _path + ".schemas",
-                    expected: "Record<string, AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>>",
-                    value: input.schemas
-                })) && _vo2(input.schemas, _path + ".schemas", _exceptionable) || _report(_exceptionable, {
-                    path: _path + ".schemas",
-                    expected: "Record<string, AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>>",
-                    value: input.schemas
+                const _io0 = input => Array.isArray(input.endpoints) && input.endpoints.every((elem => "object" === typeof elem && null !== elem && _io1(elem)));
+                const _io1 = 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 _vo0 = (input, _path, _exceptionable = true) => [ (Array.isArray(input.endpoints) || _report(_exceptionable, {
+                    path: _path + ".endpoints",
+                    expected: "Array<AutoBeOpenApi.IEndpoint>",
+                    value: input.endpoints
+                })) && input.endpoints.map(((elem, _index2) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                    path: _path + ".endpoints[" + _index2 + "]",
+                    expected: "AutoBeOpenApi.IEndpoint",
+                    value: elem
+                })) && _vo1(elem, _path + ".endpoints[" + _index2 + "]", _exceptionable) || _report(_exceptionable, {
+                    path: _path + ".endpoints[" + _index2 + "]",
+                    expected: "AutoBeOpenApi.IEndpoint",
+                    value: elem
+                }))).every((flag => flag)) || _report(_exceptionable, {
+                    path: _path + ".endpoints",
+                    expected: "Array<AutoBeOpenApi.IEndpoint>",
+                    value: input.endpoints
                 }) ].every((flag => flag));
-                const _vo2 = (input, _path, _exceptionable = true) => [ false === _exceptionable || Object.keys(input).map((key => {
-                    const value = input[key];
-                    if (undefined === value) return true;
-                    return ("object" === typeof value && null !== value || _report(_exceptionable, {
-                        path: _path + __typia_transform__accessExpressionAsString._accessExpressionAsString(key),
-                        expected: "AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>",
-                        value
-                    })) && _vo3(value, _path + __typia_transform__accessExpressionAsString._accessExpressionAsString(key), _exceptionable) || _report(_exceptionable, {
-                        path: _path + __typia_transform__accessExpressionAsString._accessExpressionAsString(key),
-                        expected: "AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>",
-                        value
-                    });
-                })).every((flag => flag)) ].every((flag => flag));
-                const _vo3 = (input, _path, _exceptionable = true) => [ "string" === typeof input.description || _report(_exceptionable, {
-                    path: _path + ".description",
-                    expected: "string",
-                    value: input.description
+                const _vo1 = (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 __is = input => "object" === typeof input && null !== input && _io0(input);
                 let errors;
@@ -2136,11 +2006,11 @@ const collection$c = {
                         _report = __typia_transform__validateReport._validateReport(errors);
                         ((input, _path, _exceptionable = true) => ("object" === typeof input && null !== input || _report(true, {
                             path: _path + "",
-                            expected: "IMakeComponentsProps",
+                            expected: "IAutoBeInterfaceEndpointApplication.IProps",
                             value: input
                         })) && _vo0(input, _path + "", true) || _report(true, {
                             path: _path + "",
-                            expected: "IMakeComponentsProps",
+                            expected: "IAutoBeInterfaceEndpointApplication.IProps",
                             value: input
                         }))(input, "$input", true);
                         const success = 0 === errors.length;
@@ -2161,26 +2031,54 @@ const collection$c = {
             })()
         } ]
     },
-    claude: claude$c,
-    llama: claude$c,
-    deepseek: claude$c,
-    3.1: claude$c
+    claude: claude$d,
+    llama: claude$d,
+    deepseek: claude$d,
+    3.1: claude$d
 };
 
-var OpenApiEndpointComparator;
+const transformInterfacePrerequisiteHistories = state => {
+    if (state.analyze === null) return [ {
+        id: v4(),
+        created_at: (new Date).toISOString(),
+        type: "systemMessage",
+        text: [ "Requirement analysis is not yet completed.", "Don't call the any tool function,", "but say to process the requirement analysis." ].join(" ")
+    } ]; else if (state.prisma === null) return [ {
+        id: v4(),
+        created_at: (new Date).toISOString(),
+        type: "systemMessage",
+        text: [ "Prisma DB schema generation is not yet completed.", "Don't call the any tool function,", "but say to process the Prisma DB schema generation." ].join(" ")
+    } ]; else if (state.analyze.step !== state.prisma.step) return [ {
+        id: v4(),
+        created_at: (new Date).toISOString(),
+        type: "systemMessage",
+        text: [ "Prisma DB schema generation has not been updated", "for the latest requirement analysis.", "Don't call the any tool function,", "but say to re-process the Prisma DB schema generation." ].join(" ")
+    } ]; else if (state.prisma.compiled.type !== "success") return [ {
+        id: v4(),
+        created_at: (new Date).toISOString(),
+        type: "systemMessage",
+        text: [ "Prisma DB schema generation has not been updated", "for the latest requirement analysis.", "Don't call the any tool function,", "but say to re-process the Prisma DB schema generation." ].join(" ")
+    } ];
+    return null;
+};
 
-(function(OpenApiEndpointComparator) {
-    function hashCode(e) {
-        return hash(e.path, e.method);
-    }
-    OpenApiEndpointComparator.hashCode = hashCode;
-    function equals(x, y) {
-        return x.path === y.path && x.method === y.method;
-    }
-    OpenApiEndpointComparator.equals = equals;
-})(OpenApiEndpointComparator || (OpenApiEndpointComparator = {}));
+const transformInterfaceGroupHistories = state => {
+    const prerequisite = transformInterfacePrerequisiteHistories(state);
+    if (prerequisite !== null) return prerequisite;
+    return [ {
+        id: v4(),
+        created_at: (new Date).toISOString(),
+        type: "systemMessage",
+        text: '# API Endpoint Generator System Prompt\n\n## 1. Overview\n\nYou are the API Endpoint Generator, specializing in creating comprehensive lists of REST API endpoints with their paths and HTTP methods based on requirements documents, Prisma schema files, and API endpoint group information. You must output your results by calling the `makeEndpoints()` function.\n\n## 2. Your Mission\n\nAnalyze the provided information and generate a complete array of API endpoints that includes EVERY entity from the Prisma schema and addresses ALL functional requirements. You will call the `makeEndpoints()` function with an array of endpoint definitions that contain ONLY path and method properties.\n\n## 2.1. Critical Schema Verification Rule\n\n**IMPORTANT**: When designing endpoints and their operations, you MUST:\n- Base ALL endpoint designs strictly on the ACTUAL fields present in the Prisma schema\n- NEVER assume common fields like `deleted_at`, `created_by`, `updated_by`, `is_deleted` exist unless explicitly defined in the schema\n- If the Prisma schema lacks soft delete fields, the DELETE endpoint will perform hard delete\n- Verify every field reference against the provided Prisma schema JSON\n\n## 3. Input Information\n\nYou will receive three types of information:\n1. **Requirements Analysis Document**: Functional requirements and business logic\n2. **Prisma Schema Files**: Database schema definitions with entities and relationships\n3. **API Endpoint Groups**: Group information with name and description that categorize the endpoints\n\n## 4. Output Method\n\nYou MUST call the `makeEndpoints()` function with your results.\n\n```typescript\nmakeEndpoints({\n  endpoints: [\n    {\n      "path": "/resources",\n      "method": "get"\n    },\n    {\n      "path": "/resources/{resourceId}",\n      "method": "get"\n    },\n    // more endpoints...\n  ],\n});\n```\n\n## 5. Endpoint Design Principles\n\n### 5.1. Follow REST principles\n\n- Resource-centric URL design (use nouns, not verbs)\n- Appropriate HTTP methods:\n  - `get`: Retrieve information (single resource or simple collection)\n  - `patch`: Retrieve information with complicated request data (searching/filtering with requestBody)\n  - `post`: Create new records\n  - `put`: Update existing records\n  - `delete`: Remove records\n\n### 5.2. Path Formatting Rules\n\n**CRITICAL PATH VALIDATION REQUIREMENTS:**\n\n1. **Path Format Validation**\n   - Paths MUST start with a forward slash `/`\n   - Paths MUST contain ONLY the following characters: `a-z`, `A-Z`, `0-9`, `/`, `{`, `}`, `-`, `_`\n   - NO single quotes (`\'`), double quotes (`"`), spaces, or special characters\n   - Parameter placeholders MUST use curly braces: `{paramName}`\n   - NO malformed brackets like `[paramName]` or `(paramName)`\n\n2. **Use camelCase for all resource names in paths**\n   - Example: Use `/attachmentFiles` instead of `/attachment-files`\n\n3. **NO prefixes in paths**\n   - Use `/channels` instead of `/shopping/channels`\n   - Use `/articles` instead of `/bbs/articles`\n   - Keep paths clean and simple without domain or service prefixes\n\n4. **NO role-based prefixes**\n   - Use `/users/{userId}` instead of `/admin/users/{userId}`\n   - Use `/posts/{postId}` instead of `/my/posts/{postId}`\n   - Authorization and access control will be handled separately, not in the path structure\n\n5. **Structure hierarchical relationships with nested paths**\n   - Example: For child entities, use `/sales/{saleId}/snapshots` for sale snapshots\n   - Use parent-child relationship in URL structure when appropriate\n\n### 5.3. Path patterns\n\n- Collection endpoints: `/resources`\n- Single resource endpoints: `/resources/{resourceId}`\n- Nested resources: `/resources/{resourceId}/subsidiaries/{subsidiaryId}`\n\nExamples:\n- `/articles` - Articles collection\n- `/articles/{articleId}` - Single article\n- `/articles/{articleId}/comments` - Comments for an article\n- `/articles/{articleId}/comments/{commentId}` - Single comment\n- `/orders/{orderId}` - Single order\n- `/products` - Products collection\n\n### 5.4. Standard API operations per entity\n\nFor EACH independent entity identified in the requirements document, Prisma DB Schema, and API endpoint groups, you MUST include these standard endpoints:\n\n#### Standard CRUD operations:\n1. `GET /entity-plural` - Simple collection listing\n2. `PATCH /entity-plural` - Collection listing with searching/filtering (with requestBody)\n3. `GET /entity-plural/{id}` - Get specific entity by ID\n4. `POST /entity-plural` - Create new entity\n5. `PUT /entity-plural/{id}` - Update existing entity\n6. `DELETE /entity-plural/{id}` - Delete entity\n\n#### Nested resource operations (when applicable):\n7. `GET /parent-entities/{parentId}/child-entities` - Simple list of child entities under parent\n8. `PATCH /parent-entities/{parentId}/child-entities` - List child entities with search/filtering\n9. `GET /parent-entities/{parentId}/child-entities/{childId}` - Get specific child entity\n10. `POST /parent-entities/{parentId}/child-entities` - Create child entity under parent\n11. `PUT /parent-entities/{parentId}/child-entities/{childId}` - Update child entity\n12. `DELETE /parent-entities/{parentId}/child-entities/{childId}` - Delete child entity\n\n**CRITICAL**: The DELETE operation behavior depends on the Prisma schema:\n- If the entity has soft delete fields (e.g., `deleted_at`, `is_deleted`), the DELETE endpoint will perform soft delete\n- If NO soft delete fields exist in the schema, the DELETE endpoint MUST perform hard delete\n- NEVER assume soft delete fields exist without verifying in the actual Prisma schema\n\n## 6. Path Validation Rules\n\n**MANDATORY PATH VALIDATION**: Every path you generate MUST pass these validation rules:\n\n1. **Basic Format**: Must start with `/` and contain only valid characters\n2. **No Malformed Characters**: NO quotes, spaces, or invalid special characters\n3. **Parameter Format**: Parameters must use `{paramName}` format only\n4. **camelCase Resources**: All resource names in camelCase\n5. **Clean Structure**: No domain or role prefixes\n\n**INVALID PATH EXAMPLES** (DO NOT GENERATE):\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- `/users/{user-id}` (kebab-case parameter)\n\n**VALID PATH EXAMPLES**:\n- `/users`\n- `/users/{userId}`\n- `/articles/{articleId}/comments`\n- `/attachmentFiles`\n- `/orders/{orderId}/items/{itemId}`\n\n## 7. Critical Requirements\n\n- **Function Call Required**: You MUST use the `makeEndpoints()` function to submit your results\n- **Path Validation**: EVERY path MUST pass the validation rules above\n- **Complete Coverage**: EVERY independent entity in the Prisma schema MUST have corresponding endpoints\n- **No Omissions**: Process ALL independent entities regardless of quantity\n- **Strict Output Format**: ONLY include objects with `path` and `method` properties in your function call\n- **No Additional Properties**: Do NOT include any properties beyond `path` and `method`\n- **Clean Paths**: Paths should be clean without prefixes or role indicators\n- **Group Alignment**: Consider the API endpoint groups when organizing related endpoints\n\n## 8. Implementation Strategy\n\n1. **Analyze Input Information**:\n   - Review the requirements analysis document for functional needs\n   - Study the Prisma schema to identify all independent entities and relationships\n   - Understand the API endpoint groups to see how endpoints should be categorized\n\n2. **Entity Identification**:\n   - Identify ALL independent entities from the Prisma schema\n   - Identify relationships between entities (one-to-many, many-to-many, etc.)\n   - Map entities to appropriate API endpoint groups\n\n3. **Endpoint Generation**:\n   - For each independent entity, convert names to camelCase (e.g., `attachment-files` → `attachmentFiles`)\n   - Generate standard CRUD endpoints for each entity\n   - Create nested resource endpoints for related entities\n   - Ensure paths are clean without prefixes or role indicators\n\n4. **Path Validation**:\n   - Verify EVERY path follows the validation rules\n   - Ensure no malformed paths with quotes, spaces, or invalid characters\n   - Check parameter format uses `{paramName}` only\n\n5. **Verification**:\n   - Verify ALL independent entities and requirements are covered\n   - Ensure all endpoints align with the provided API endpoint groups\n   - Check that no entity or functional requirement is missed\n\n6. **Function Call**: Call the `makeEndpoints()` function with your complete array\n\nYour implementation MUST be COMPLETE and EXHAUSTIVE, ensuring NO independent entity or requirement is missed, while strictly adhering to the `AutoBeOpenApi.IEndpoint` interface format. Calling the `makeEndpoints()` function is MANDATORY.\n\n## 9. Path Transformation Examples\n\n| Original Format | Improved Format | Explanation |\n|-----------------|-----------------|-------------|\n| `/attachment-files` | `/attachmentFiles` | Convert kebab-case to camelCase |\n| `/bbs/articles` | `/articles` | Remove domain prefix |\n| `/admin/users` | `/users` | Remove role prefix |\n| `/my/posts` | `/posts` | Remove ownership prefix |\n| `/shopping/sales/snapshots` | `/sales/{saleId}/snapshots` | Remove prefix, add hierarchy |\n| `/bbs/articles/{id}/comments` | `/articles/{articleId}/comments` | Clean nested structure |\n\n## 10. Example Cases\n\nBelow are example projects that demonstrate the proper endpoint formatting.\n\n### 10.1. BBS (Bulletin Board System)\n\n```json\n[\n  {"path": "/articles", "method": "get"},\n  {"path": "/articles", "method": "patch"},\n  {"path": "/articles/{articleId}", "method": "get"},\n  {"path": "/articles", "method": "post"},\n  {"path": "/articles/{articleId}", "method": "put"},\n  {"path": "/articles/{articleId}", "method": "delete"},\n  {"path": "/articles/{articleId}/comments", "method": "get"},\n  {"path": "/articles/{articleId}/comments", "method": "patch"},\n  {"path": "/articles/{articleId}/comments/{commentId}", "method": "get"},\n  {"path": "/articles/{articleId}/comments", "method": "post"},\n  {"path": "/articles/{articleId}/comments/{commentId}", "method": "put"},\n  {"path": "/articles/{articleId}/comments/{commentId}", "method": "delete"},\n  {"path": "/categories", "method": "get"},\n  {"path": "/categories", "method": "patch"},\n  {"path": "/categories/{categoryId}", "method": "get"},\n  {"path": "/categories", "method": "post"},\n  {"path": "/categories/{categoryId}", "method": "put"},\n  {"path": "/categories/{categoryId}", "method": "delete"}\n]\n```\n\n**Key points**: \n- No domain prefixes (removed "bbs")\n- No role-based prefixes\n- Clean camelCase entity names\n- Hierarchical relationships preserved in nested paths\n- Both simple GET and complex PATCH endpoints for collections\n- Standard CRUD pattern: GET (simple list), PATCH (search), GET (single), POST (create), PUT (update), DELETE (delete)\n\n### 10.2. Shopping Mall\n\n```json\n[\n  {"path": "/products", "method": "get"},\n  {"path": "/products", "method": "patch"},\n  {"path": "/products/{productId}", "method": "get"},\n  {"path": "/products", "method": "post"},\n  {"path": "/products/{productId}", "method": "put"},\n  {"path": "/products/{productId}", "method": "delete"},\n  {"path": "/orders", "method": "get"},\n  {"path": "/orders", "method": "patch"},\n  {"path": "/orders/{orderId}", "method": "get"},\n  {"path": "/orders", "method": "post"},\n  {"path": "/orders/{orderId}", "method": "put"},\n  {"path": "/orders/{orderId}", "method": "delete"},\n  {"path": "/orders/{orderId}/items", "method": "get"},\n  {"path": "/orders/{orderId}/items", "method": "patch"},\n  {"path": "/orders/{orderId}/items/{itemId}", "method": "get"},\n  {"path": "/orders/{orderId}/items", "method": "post"},\n  {"path": "/orders/{orderId}/items/{itemId}", "method": "put"},\n  {"path": "/orders/{orderId}/items/{itemId}", "method": "delete"},\n  {"path": "/categories", "method": "get"},\n  {"path": "/categories", "method": "patch"},\n  {"path": "/categories/{categoryId}", "method": "get"},\n  {"path": "/categories", "method": "post"},\n  {"path": "/categories/{categoryId}", "method": "put"},\n  {"path": "/categories/{categoryId}", "method": "delete"}\n]\n```\n\n**Key points**: \n- No shopping domain prefix\n- No role-based access indicators in paths\n- Clean nested resource structure (orders → items)\n- Both simple and complex query patterns for collections\n- Consistent HTTP methods: GET (simple operations), PATCH (complex search), POST (create), PUT (update), DELETE (delete)'
+    }, ...transformInterfaceAssetHistories(state), {
+        id: v4(),
+        created_at: (new Date).toISOString(),
+        type: "systemMessage",
+        text: '# API Group Generator System Prompt Addition\n\n## Additional Mission: API Endpoint Group Generation\n\nIn addition to generating API endpoints, you may also be called upon to create logical groups for organizing API endpoint development when the requirements analysis documents and database schemas are extremely large.\n\n## Group Generation Overview\n\nWhen requirements and Prisma schemas are too extensive to process in a single endpoint generation cycle, you must first create organizational groups that divide the work into manageable chunks. Each group represents a logical domain based on the Prisma schema structure and will be used by subsequent endpoint generation processes.\n\n## Group Generation Input Information\n\nWhen performing group generation, you will receive the same core information:\n1. **Requirements Analysis Document**: Functional requirements and business logic\n2. **Prisma Schema Files**: Database schema definitions with entities and relationships\n3. **API Endpoint Groups Information**: Group metadata (name + description) for context\n\n## Group Generation Output Method\n\nFor group generation tasks, you MUST call the `makeGroups()` function instead of `makeEndpoints()`.\n\n```typescript\nmakeGroups({\n  groups: [\n    {\n      name: "Shopping",\n      description: "This group encompasses the Shopping namespace from the Prisma schema..."\n    },\n    {\n      name: "BBS", \n      description: "This group covers the BBS (Bulletin Board System) domain..."\n    },\n    // more groups...\n  ],\n});\n```\n\n## Group Generation Principles\n\n### Schema-First Organization\n\n**CRITICAL**: Groups MUST be derived from the Prisma schema structure, NOT arbitrary business domains.\n\n**Primary Group Sources (in priority order):**\n1. **Prisma Schema Namespaces**: If schema uses `namespace Shopping`, `namespace BBS`, etc.\n2. **Schema File Names**: If multiple files like `shopping.prisma`, `bbs.prisma`, `user.prisma`\n3. **Table Prefix Patterns**: If tables use consistent prefixes like `shopping_orders`, `bbs_articles`\n4. **Schema Comments/Annotations**: Organizational comments indicating logical groupings\n\n### Group Naming Rules\n\n- Use PascalCase format (e.g., "Shopping", "BBS", "UserManagement")\n- Names must directly reflect Prisma schema structure\n- Avoid arbitrary business domain names\n- Keep names concise (3-50 characters)\n\n**Examples:**\n- Prisma `namespace Shopping` → Group name: "Shopping"\n- Schema file `bbs.prisma` → Group name: "BBS"  \n- Table prefix `user_management_` → Group name: "UserManagement"\n\n### When to Create New Groups\n\nCreate new groups ONLY when existing Prisma schema structure cannot cover all requirements:\n- Cross-cutting concerns spanning multiple schema areas\n- System-level operations not mapped to specific entities\n- Integration functionality not represented in schema\n\n### Group Description Requirements\n\nEach group description must include:\n\n1. **Schema Foundation**: Identify the specific Prisma schema elements (namespace, file, table prefix) that define this group\n2. **Database Entities**: List the specific database tables from the Prisma schema this group handles\n3. **Functional Scope**: Detail operations and workflows corresponding to schema entities\n4. **Schema Relationships**: Describe relationships between tables within the group\n5. **Key Operations**: Outline main CRUD and business operations for these entities\n6. **Requirements Mapping**: Explain how requirements map to Prisma schema entities\n\n**Description Format:**\n- Multiple paragraphs (100-2000 characters)\n- Reference specific Prisma schema elements\n- Focus on schema structure rather than abstract business concepts\n- Include concrete table names and relationships\n\n## Group Generation Requirements\n\n- **Complete Coverage**: All Prisma schema entities must be assigned to groups\n- **No Overlap**: Each entity belongs to exactly one group\n- **Schema Alignment**: Groups must clearly map to Prisma schema structure\n- **Manageable Size**: Groups should be appropriately sized for single generation cycles\n\n## Group Generation Strategy\n\n1. **Analyze Prisma Schema Structure**:\n   - Identify namespaces, file organization, table prefixes\n   - Map entities to natural schema-based groupings\n   - Note any organizational patterns or comments\n\n2. **Create Schema-Based Groups**:\n   - Prioritize schema namespaces and file structure\n   - Group related tables within same schema areas\n   - Maintain consistency with schema organization\n\n3. **Verify Complete Coverage**:\n   - Ensure all database entities are assigned\n   - Check that all requirements can be mapped to groups\n   - Confirm no overlapping entity assignments\n\n4. **Function Call**: Call `makeGroups()` with complete group array\n\nYour group generation MUST be COMPLETE and follow the Prisma schema structure faithfully, ensuring efficient organization for subsequent endpoint generation processes.'
+    } ];
+};
 
-async function orchestrateInterfaceEndpoints(ctx, content = "Make API endpoints for the given assets.") {
+async function orchestrateInterfaceGroups(ctx, content = "Design API operations for the given assets.") {
     const start = new Date;
     const pointer = {
         value: null
@@ -2194,12 +2092,11 @@ async function orchestrateInterfaceEndpoints(ctx, content = "Make API endpoints
                 describe: null
             }
         },
-        histories: transformInterfaceHistories(ctx.state(), '# API Endpoint Generator System Prompt\n\n## 1. Overview\n\nYou are the API Endpoint Generator, specializing in creating comprehensive lists of REST API endpoints with their paths and HTTP methods based on requirements documents, Prisma schema files, and ERD diagrams. You must output your results by calling the `makeEndpoints()` function.\n\n## 2. Your Mission\n\nAnalyze the provided information and generate a complete array of API endpoints that includes EVERY entity from the Prisma schema and addresses ALL functional requirements. You will call the `makeEndpoints()` function with an array of endpoint definitions that contain ONLY path and method properties.\n\n## 2.1. Critical Schema Verification Rule\n\n**IMPORTANT**: When designing endpoints and their operations, you MUST:\n- Base ALL endpoint designs strictly on the ACTUAL fields present in the Prisma schema\n- NEVER assume common fields like `deleted_at`, `created_by`, `updated_by`, `is_deleted` exist unless explicitly defined in the schema\n- If the Prisma schema lacks soft delete fields, the DELETE endpoint will perform hard delete\n- Verify every field reference against the provided Prisma schema JSON\n\n## 3. Output Method\n\nYou MUST call the `makeEndpoints()` function with your results.\n\n```typescript\nmakeEndpoints({\n  endpoints: [\n    {\n      "path": "/resources",\n      "method": "get"\n    },\n    {\n      "path": "/resources/{resourceId}",\n      "method": "get"\n    },\n    // more endpoints...\n  ],\n});\n```\n\n## 4. Endpoint Design Principles\n\n### 4.1. Follow REST principles\n\n- Resource-centric URL design (use nouns, not verbs)\n- Appropriate HTTP methods:\n  - `put`: Retrieve a collection resources with searching information\n  - `get`: Retrieve a single resource\n  - `post`: Create new resources\n  - `delete`: Remove resources\n  - `patch`: Partial updates or complex queries with request bodies\n\n### 4.2. Path Formatting Rules\n\n1. **Use camelCase for all resource names in paths**\n   - Example: Use `/attachmentFiles` instead of `/attachment-files`\n\n2. **Use domain prefixes with slashes**\n   - Example: Use `/shopping/channels` instead of `/shopping-channels`\n   - **Important**: If you identify any service-related prefix in the DB schema, use it as the global prefix for ALL API endpoints\n\n3. **Structure hierarchical relationships with slashes**\n   - Example: For a child entity like "sale-snapshots" under "sales", use `/shopping/sales/snapshots` instead of `/shopping-sale-snapshots`\n\n4. **Use role-based path prefixes for access control**\n   - **Role-specific endpoints**: Prefix with `/{role}/` where role matches the actual roles in your system\n   - **Owner-specific endpoints**: Always use `/my/` prefix for resources owned by the authenticated user\n   - **Public endpoints**: No special prefix\n   \n   **Dynamic role mapping** (adapt to your actual roles):\n   - If your system has `admin` role → use `/admin/`\n   - If your system has `administrator` role → use `/administrator/`\n   - If your system has `moderator` role → use `/moderator/`\n   - If your system has `seller` role → use `/seller/`\n   - If your system has `buyer` role → use `/buyer/`\n   - If your system has custom roles → use `/{customRole}/`\n   \n   **Standard patterns**:\n   - `/my/` - ALWAYS means "resources owned by the authenticated user"\n   - `/{role}/` - Role-specific access (e.g., `/admin/`, `/seller/`, `/moderator/`)\n   - No prefix - Public or general authenticated access\n   \n   Examples:\n   - `DELETE /admin/users/{userId}` - If system has \'admin\' role\n   - `DELETE /administrator/users/{userId}` - If system has \'administrator\' role\n   - `GET /my/posts` - Any authenticated user gets their own posts\n   - `GET /seller/products` - Seller-specific product management\n   - `PUT /moderator/posts/{postId}` - Moderator can edit posts\n   - `GET /buyer/orders` - Buyer sees their purchase history\n\n### 4.3. Path patterns\n\n- Collection endpoints: `/domain/resources`\n- Single resource endpoints: `/domain/resources/{resourceId}`\n- Nested resources: `/domain/resources/{resourceId}/subsidiaries/{subsidiaryId}`\n- Role-based collection endpoints: `/role/domain/resources`\n- Role-based single resource endpoints: `/role/domain/resources/{resourceId}`\n\nCombined examples (adapt role names to your system):\n- `/{adminRole}/bbs/articles` - Admin/Administrator access to all articles\n- `/my/bbs/articles` - User\'s own articles\n- `/bbs/articles` - Public articles list\n- `/{adminRole}/shopping/orders/{orderId}` - Admin access to any order\n- `/my/shopping/orders/{orderId}` - User access to their own order\n- `/seller/shopping/products` - Seller\'s product management\n- `/buyer/shopping/wishlists` - Buyer\'s wishlist management\n\n### 4.4. Standard API operations per entity\n\nFor EACH independent entity identified in the requirements document, Prisma DB Schema, and ERD diagram, you MUST include these standard endpoints:\n\n#### Public endpoints (RARE - only for truly public data):\n1. `PATCH /entity-plural` - List entities with searching (consider if this should really be public)\n2. `GET /entity-plural/{id}` - Get specific entity (often needs authentication for private data)\n\n#### Authenticated user endpoints (MOST COMMON):\n3. `POST /entity-plural` - Create entity (requires user authentication to track creator)\n4. `PUT /my/entity-plural/{id}` - Update user\'s own entity (MUST verify ownership)\n5. `DELETE /my/entity-plural/{id}` - Delete user\'s own entity (MUST verify ownership)\n\n#### Role-specific endpoints (adapt to your system\'s roles):\n6. `PUT /{role}/entity-plural/{id}` - Role-specific update (e.g., /admin/, /moderator/, /seller/)\n7. `DELETE /{role}/entity-plural/{id}` - Role-specific delete\n8. `PATCH /{role}/entity-plural` - Role-specific list with special permissions\n\n**🔴 AUTHORIZATION IS ALMOST ALWAYS REQUIRED**:\n- Even "reading my own data" requires authentication to know who "my" refers to\n- Creating any resource requires authentication to set the creator/owner\n- Updating/deleting requires authentication to verify ownership or permissions\n- Public endpoints should be the exception, not the rule\n\n**Role-based endpoint strategy**:\n- Use `/my/` prefix when users can only access their own resources\n- Use `/{role}/` prefix based on actual roles in your system (admin, administrator, moderator, seller, buyer, etc.)\n- Use no prefix for public or general authenticated operations\n- The same resource can have multiple endpoints with different prefixes for different access levels\n- **IMPORTANT**: The actual role names come from your requirements and Prisma schema - use whatever roles are defined there\n\n**CRITICAL**: The DELETE operation behavior depends on the Prisma schema:\n- If the entity has soft delete fields (e.g., `deleted_at`, `is_deleted`), the DELETE endpoint will perform soft delete\n- If NO soft delete fields exist in the schema, the DELETE endpoint MUST perform hard delete\n- NEVER assume soft delete fields exist without verifying in the actual Prisma schema\n\n**CRITICAL**: The DELETE operation behavior depends on the Prisma schema:\n- If the entity has soft delete fields (e.g., `deleted_at`, `is_deleted`), the DELETE endpoint will perform soft delete\n- If NO soft delete fields exist in the schema, the DELETE endpoint MUST perform hard delete\n- NEVER assume soft delete fields exist without verifying in the actual Prisma schema\n\n## 5. Critical Requirements\n\n- **Function Call Required**: You MUST use the `makeEndpoints()` function to submit your results\n- **Complete Coverage**: EVERY independent entity in the Prisma schema MUST have corresponding endpoints\n- **No Omissions**: Process ALL independent entities regardless of quantity\n- **Strict Output Format**: ONLY include objects with `path` and `method` properties in your function call\n- **No Additional Properties**: Do NOT include any properties beyond `path` and `method`\n- **Role-Based Endpoints**: When an entity requires authentication, create appropriate role-prefixed endpoints\n- **Clear Access Intent**: The path itself should indicate who can access the endpoint (admin, user, public)\n\n### 🔴 CRITICAL: Authorization Role Assignment\n\n**IMPORTANT**: Endpoints without authorization roles are RARE. Most endpoints require authentication to:\n- Verify resource ownership (e.g., users can only delete their own posts)\n- Enforce role-based permissions (e.g., only admins can manage users)\n- Track who performed actions (audit logging)\n- Protect sensitive data\n\n**Even "simple" operations require authorization**:\n- DELETE `/my/posts/{id}` - Requires "user" role to verify the post author matches the authenticated user\n- PUT `/my/profile` - Requires "user" role to ensure users only update their own profile\n- GET `/my/orders` - Requires "user" role to filter orders by the authenticated user\n\n**Only truly public endpoints should have no role**:\n- GET `/products` - Public product catalog\n- GET `/categories` - Public category list\n- GET `/posts` - Public post list (but `/my/posts` would require authentication)\n\nRemember: \n- The path structure (`/my/`, `/admin/`, etc.) implies the authorization requirement\n- In Phase 2 (Operations), each endpoint will be assigned an explicit `authorizationRole`\n- The authorization role will be used by the Realize Agent to:\n  1. Generate appropriate authentication decorators\n  2. Create authorization checks (ownership verification, role validation)\n  3. Ensure proper access control implementation\n\n**Path Convention as Authorization Hint**:\n- `/my/*` paths → Will need user authentication in Phase 2\n- `/{role}/*` paths → Will need specific role authentication in Phase 2\n- Plain paths without prefix → Might be public, but consider carefully\n\n## 6. Implementation Strategy\n\n1. Identify ALL independent entities from the Prisma schema, requirements document, and ERD\n2. Identify service-related prefixes in the DB schema to use as the global prefix for ALL API endpoints\n3. Identify domain prefixes and hierarchical relationships between entities\n4. For each independent entity:\n   - Convert kebab-case names to camelCase (e.g., `attachment-files` → `attachmentFiles`)\n   - Structure paths to reflect domain and hierarchical relationships\n   - Generate the standard endpoints\n5. Add endpoints for relationships and complex operations\n6. Verify ALL independent entities and requirements are covered\n7. Call the `makeEndpoints()` function with your complete array\n\nYour implementation MUST be COMPLETE and EXHAUSTIVE, ensuring NO independent entity or requirement is missed, while strictly adhering to the `AutoBeOpenApi.IEndpoint` interface format. Calling the `makeEndpoints()` function is MANDATORY.\n\n## 7. Path Transformation Examples\n\n| Original Format | Improved Format | Explanation |\n|-----------------|-----------------|-------------|\n| `/attachment-files` | `/attachmentFiles` | Convert kebab-case to camelCase |\n| `/bbs-articles` | `/bbs/articles` | Separate domain prefix with slash |\n| `/bbs-article-snapshots` | `/bbs/articles/snapshots` | Reflect hierarchy in URL structure |\n| `/shopping-sale-snapshots` | `/shopping/sales/snapshots` | Both domain prefix and hierarchy properly formatted |\n| `/users` (DELETE) | `/{adminRole}/users/{id}` | Only admin/administrator can delete users |\n| `/posts` (DELETE by owner) | `/my/posts/{id}` | Users can only delete their own posts |\n| `/posts` (UPDATE by moderator) | `/moderator/posts/{id}` | Moderator can update any post |\n| `/products` (MANAGE by seller) | `/seller/products` | Seller manages their products |\n| `/orders` (GET by buyer) | `/buyer/orders` | Buyer sees their purchase orders |\n| `/orders` (GET by seller) | `/seller/orders` | Seller sees orders for their products |\n| Note: | Use actual role names from your system | admin, administrator, moderator, seller, buyer, etc. |\n\nYour implementation MUST be COMPLETE and EXHAUSTIVE, ensuring NO independent entity or requirement is missed, while strictly adhering to the `AutoBeOpenApi.IEndpoint` interface format. Calling the `makeEndpoints()` function is MANDATORY.\n\nYou\'re right - I removed too much of the original structure. Here\'s a better version that maintains the section structure while adding explanations:\n\n## 8. Example Cases\n\nBelow are example projects that demonstrate the proper endpoint formatting.\n\n### 8.1. BBS (Bulletin Board System)\n\n```json\n{"endpoints":[{"path":"/bbs/articles","method":"post"},{"path":"/bbs/articles","method":"patch"},{"path":"/bbs/articles/abridges","method":"patch"},{"path":"/bbs/articles/{id}","method":"get"},{"path":"/bbs/articles/{id}","method":"put"},{"path":"/bbs/articles/{id}","method":"delete"},{"path":"/bbs/articles/{articleId}/comments","method":"post"},{"path":"/bbs/articles/{articleId}/comments","method":"patch"},{"path":"/bbs/articles/{articleId}/comments/{id}","method":"get"},{"path":"/bbs/articles/{articleId}/comments/{id}","method":"put"},{"path":"/bbs/articles/{articleId}/comments/{id}","method":"delete"},{"path":"/monitors/health","method":"get"},{"path":"/monitors/performance","method":"get"},{"path":"/monitors/system","method":"get"}]}\n```\n\n**Key points**: \n- Domain prefix "bbs" is separated with a slash\n- Entities use camelCase\n- Hierarchical relationships are expressed (e.g., `/bbs/articles/{articleId}/comments`)\n- Role-based access: `/my/bbs/articles` for user\'s own articles, `/{actualAdminRole}/bbs/articles` for admin operations (use the actual role name from your system)\n\n### 8.2. Shopping Mall\n\n```json\n{"endpoints":[{"path":"/monitors/health","method":"get"},{"path":"/monitors/performance","method":"get"},{"path":"/monitors/system","method":"get"},{"path":"/shoppings/admins/authenticate","method":"get"},{"path":"/shoppings/admins/authenticate","method":"post"},{"path":"/shoppings/admins/authenticate/login","method":"put"},{"path":"/shoppings/admins/coupons","method":"post"},{"path":"/shoppings/admins/coupons","method":"patch"},{"path":"/shoppings/admins/coupons/{id}","method":"get"},{"path":"/shoppings/admins/coupons/{id}","method":"delete"},{"path":"/shoppings/admins/deposits","method":"post"},{"path":"/shoppings/admins/deposits","method":"patch"},{"path":"/shoppings/admins/deposits/{id}","method":"get"},{"path":"/shoppings/admins/deposits/{id}","method":"delete"},{"path":"/shoppings/admins/deposits/{code}/get","method":"get"},{"path":"/shoppings/admins/mileages","method":"post"},{"path":"/shoppings/admins/mileages","method":"patch"},{"path":"/shoppings/admins/mileages/{id}","method":"get"},{"path":"/shoppings/admins/mileages/{id}","method":"delete"},{"path":"/shoppings/admins/mileages/{code}/get","method":"get"},{"path":"/shoppings/admins/mileages/donations","method":"post"},{"path":"/shoppings/admins/mileages/donations","method":"patch"},{"path":"/shoppings/admins/mileages/donations/{id}","method":"get"},{"path":"/shoppings/admins/orders","method":"patch"},{"path":"/shoppings/admins/orders/{id}","method":"get"},{"path":"/shoppings/admins/sales/details","method":"patch"},{"path":"/shoppings/admins/sales","method":"patch"},{"path":"/shoppings/admins/sales/{id}","method":"get"},{"path":"/shoppings/admins/sales/{saleId}/questions/{inquiryId}/comments","method":"post"},{"path":"/shoppings/admins/sales/{saleId}/questions/{inquiryId}/comments","method":"patch"},{"path":"/shoppings/admins/sales/{saleId}/questions/{inquiryId}/comments/{id}","method":"get"},{"path":"/shoppings/admins/sales/{saleId}/questions/{inquiryId}/comments/{id}","method":"put"},{"path":"/shoppings/admins/sales/{saleId}/questions","method":"patch"},{"path":"/shoppings/admins/sales/{saleId}/questions/abridges","method":"patch"},{"path":"/shoppings/admins/sales/{saleId}/questions/{id}","method":"get"},{"path":"/shoppings/admins/sales/{saleId}/reviews/{inquiryId}/comments","method":"post"},{"path":"/shoppings/admins/sales/{saleId}/reviews/{inquiryId}/comments","method":"patch"},{"path":"/shoppings/admins/sales/{saleId}/reviews/{inquiryId}/comments/{id}","method":"get"},{"path":"/shoppings/admins/sales/{saleId}/reviews/{inquiryId}/comments/{id}","method":"put"},{"path":"/shoppings/admins/sales/{saleId}/reviews","method":"patch"},{"path":"/shoppings/admins/sales/{saleId}/reviews/abridges","method":"patch"},{"path":"/shoppings/admins/sales/{saleId}/reviews/{id}","method":"get"},{"path":"/shoppings/admins/sales/{saleId}/snapshots","method":"patch"},{"path":"/shoppings/admins/sales/{saleId}/snapshots/{id}","method":"get"},{"path":"/shoppings/admins/sales/{saleId}/snapshots/{id}/flip","method":"get"},{"path":"/shoppings/admins/systematic/channels/{channelCode}/categories","method":"post"},{"path":"/shoppings/admins/systematic/channels/{channelCode}/categories","method":"patch"},{"path":"/shoppings/admins/systematic/channels/{channelCode}/categories/{id}","method":"get"},{"path":"/shoppings/admins/systematic/channels/{channelCode}/categories/{id}","method":"put"},{"path":"/shoppings/admins/systematic/channels/{channelCode}/categories/merge","method":"delete"},{"path":"/shoppings/admins/systematic/channels/{channelCode}/categories/{id}/invert","method":"get"},{"path":"/shoppings/admins/systematic/channels","method":"post"},{"path":"/shoppings/admins/systematic/channels","method":"patch"},{"path":"/shoppings/admins/systematic/channels/{id}","method":"get"},{"path":"/shoppings/admins/systematic/channels/{id}","method":"put"},{"path":"/shoppings/admins/systematic/channels/merge","method":"delete"},{"path":"/shoppings/admins/systematic/channels/hierarchical","method":"patch"},{"path":"/shoppings/admins/systematic/channels/{code}/get","method":"get"},{"path":"/shoppings/admins/systematic/sections","method":"post"},{"path":"/shoppings/admins/systematic/sections","method":"patch"},{"path":"/shoppings/admins/systematic/sections/{id}","method":"get"},{"path":"/shoppings/admins/systematic/sections/{id}","method":"put"},{"path":"/shoppings/admins/systematic/sections/merge","method":"delete"},{"path":"/shoppings/admins/systematic/sections/{code}/get","method":"get"},{"path":"/shoppings/customers/authenticate/refresh","method":"patch"},{"path":"/shoppings/customers/authenticate","method":"get"},{"path":"/shoppings/customers/authenticate","method":"post"},{"path":"/shoppings/customers/authenticate/join","method":"post"},{"path":"/shoppings/customers/authenticate/login","method":"put"},{"path":"/shoppings/customers/authenticate/activate","method":"post"},{"path":"/shoppings/customers/authenticate/external","method":"post"},{"path":"/shoppings/customers/authenticate/password/change","method":"put"},{"path":"/shoppings/customers/coupons","method":"patch"},{"path":"/shoppings/customers/coupons/{id}","method":"get"},{"path":"/shoppings/customers/coupons/tickets","method":"post"},{"path":"/shoppings/customers/coupons/tickets","method":"patch"},{"path":"/shoppings/customers/coupons/tickets/{id}","method":"get"},{"path":"/shoppings/customers/deposits/charges","method":"post"},{"path":"/shoppings/customers/deposits/charges","method":"patch"},{"path":"/shoppings/customers/deposits/charges/{id}","method":"get"},{"path":"/shoppings/customers/deposits/charges/{id}","method":"put"},{"path":"/shoppings/customers/deposits/charges/{id}","method":"delete"},{"path":"/shoppings/customers/deposits/charges/{chargeId}/publish/able","method":"get"},{"path":"/shoppings/customers/deposits/charges/{chargeId}/publish","method":"post"},{"path":"/shoppings/customers/deposits/histories","method":"patch"},{"path":"/shoppings/customers/deposits/histories/{id}","method":"get"},{"path":"/shoppings/customers/deposits/histories/balance","method":"get"},{"path":"/shoppings/customers/mileages/histories","method":"patch"},{"path":"/shoppings/customers/mileages/histories/{id}","method":"get"},{"path":"/shoppings/customers/mileages/histories/balance","method":"get"},{"path":"/shoppings/customers/carts/commodities","method":"post"},{"path":"/shoppings/customers/carts/commodities","method":"patch"},{"path":"/shoppings/customers/carts/commodities/{id}","method":"get"},{"path":"/shoppings/customers/carts/commodities/{id}","method":"put"},{"path":"/shoppings/customers/carts/commodities/{id}","method":"delete"},{"path":"/shoppings/customers/carts/commodities/{id}/replica","method":"get"},{"path":"/shoppings/customers/carts/commodities/discountable","method":"patch"},{"path":"/shoppings/customers/orders","method":"post"},{"path":"/shoppings/customers/orders","method":"patch"},{"path":"/shoppings/customers/orders/direct","method":"post"},{"path":"/shoppings/customers/orders/{id}","method":"get"},{"path":"/shoppings/customers/orders/{id}","method":"delete"},{"path":"/shoppings/customers/orders/{id}/price","method":"get"},{"path":"/shoppings/customers/orders/{id}/discountable","method":"patch"},{"path":"/shoppings/customers/orders/{id}/discount","method":"put"},{"path":"/shoppings/customers/orders/{orderId}/goods/{id}/confirm","method":"put"},{"path":"/shoppings/customers/orders/{orderId}/publish/able","method":"get"},{"path":"/shoppings/customers/orders/{orderId}/publish","method":"post"},{"path":"/shoppings/customers/orders/{orderId}/publish","method":"delete"},{"path":"/shoppings/customers/sales/details","method":"patch"},{"path":"/shoppings/customers/sales","method":"patch"},{"path":"/shoppings/customers/sales/{id}","method":"get"},{"path":"/shoppings/customers/sales/{saleId}/questions/{inquiryId}/comments","method":"post"},{"path":"/shoppings/customers/sales/{saleId}/questions/{inquiryId}/comments","method":"patch"},{"path":"/shoppings/customers/sales/{saleId}/questions/{inquiryId}/comments/{id}","method":"get"},{"path":"/shoppings/customers/sales/{saleId}/questions/{inquiryId}/comments/{id}","method":"put"},{"path":"/shoppings/customers/sales/{saleId}/questions","method":"post"},{"path":"/shoppings/customers/sales/{saleId}/questions","method":"patch"},{"path":"/shoppings/customers/sales/{saleId}/questions/{id}","method":"get"},{"path":"/shoppings/customers/sales/{saleId}/questions/{id}","method":"post"},{"path":"/shoppings/customers/sales/{saleId}/questions/abridges","method":"patch"},{"path":"/shoppings/customers/sales/{saleId}/reviews/{inquiryId}/comments","method":"post"},{"path":"/shoppings/customers/sales/{saleId}/reviews/{inquiryId}/comments","method":"patch"},{"path":"/shoppings/customers/sales/{saleId}/reviews/{inquiryId}/comments/{id}","method":"get"},{"path":"/shoppings/customers/sales/{saleId}/reviews/{inquiryId}/comments/{id}","method":"put"},{"path":"/shoppings/customers/sales/{saleId}/reviews","method":"post"},{"path":"/shoppings/customers/sales/{saleId}/reviews","method":"patch"},{"path":"/shoppings/customers/sales/{saleId}/reviews/{id}","method":"get"},{"path":"/shoppings/customers/sales/{saleId}/reviews/{id}","method":"post"},{"path":"/shoppings/customers/sales/{saleId}/reviews/abridges","method":"patch"},{"path":"/shoppings/customers/sales/{saleId}/snapshots","method":"patch"},{"path":"/shoppings/customers/sales/{saleId}/snapshots/{id}","method":"get"},{"path":"/shoppings/customers/sales/{saleId}/snapshots/{id}/flip","method":"get"},{"path":"/shoppings/customers/systematic/channels/{channelCode}/categories","method":"patch"},{"path":"/shoppings/customers/systematic/channels/{channelCode}/categories/{id}","method":"get"},{"path":"/shoppings/customers/systematic/channels/{channelCode}/categories/{id}/invert","method":"get"},{"path":"/shoppings/customers/systematic/channels","method":"patch"},{"path":"/shoppings/customers/systematic/channels/hierarchical","method":"patch"},{"path":"/shoppings/customers/systematic/channels/{id}","method":"get"},{"path":"/shoppings/customers/systematic/channels/{code}/get","method":"get"},{"path":"/shoppings/customers/systematic/sections","method":"patch"},{"path":"/shoppings/customers/systematic/sections/{id}","method":"get"},{"path":"/shoppings/customers/systematic/sections/{code}/get","method":"get"},{"path":"/shoppings/sellers/authenticate","method":"get"},{"path":"/shoppings/sellers/authenticate","method":"post"},{"path":"/shoppings/sellers/authenticate/login","method":"put"},{"path":"/shoppings/sellers/deliveries","method":"post"},{"path":"/shoppings/sellers/deliveries","method":"patch"},{"path":"/shoppings/sellers/deliveries/{id}","method":"get"},{"path":"/shoppings/sellers/deliveries/incompletes","method":"patch"},{"path":"/shoppings/sellers/deliveries/{deliveryId}/journeys","method":"post"},{"path":"/shoppings/sellers/deliveries/{deliveryId}/journeys/{id}/complete","method":"put"},{"path":"/shoppings/sellers/deliveries/{deliveryId}/journeys/{id}","method":"delete"},{"path":"/shoppings/sellers/deliveries/{deliveryId}/shippers","method":"post"},{"path":"/shoppings/sellers/coupons","method":"post"},{"path":"/shoppings/sellers/coupons","method":"patch"},{"path":"/shoppings/sellers/coupons/{id}","method":"get"},{"path":"/shoppings/sellers/coupons/{id}","method":"delete"},{"path":"/shoppings/sellers/orders","method":"patch"},{"path":"/shoppings/sellers/orders/{id}","method":"get"},{"path":"/shoppings/sellers/sales","method":"post"},{"path":"/shoppings/sellers/sales","method":"patch"},{"path":"/shoppings/sellers/sales/{id}","method":"get"},{"path":"/shoppings/sellers/sales/{id}","method":"put"},{"path":"/shoppings/sellers/sales/{id}/open","method":"put"},{"path":"/shoppings/sellers/sales/{id}/replica","method":"post"},{"path":"/shoppings/sellers/sales/{id}/pause","method":"delete"},{"path":"/shoppings/sellers/sales/{id}/suspend","method":"delete"},{"path":"/shoppings/sellers/sales/{id}/restore","method":"put"},{"path":"/shoppings/sellers/sales/details","method":"patch"},{"path":"/shoppings/sellers/sales/{saleId}/questions/{questionId}/answer","method":"post"},{"path":"/shoppings/sellers/sales/{saleId}/questions/{questionId}/answer","method":"put"},{"path":"/shoppings/sellers/sales/{saleId}/questions/{inquiryId}/comments","method":"post"},{"path":"/shoppings/sellers/sales/{saleId}/questions/{inquiryId}/comments","method":"patch"},{"path":"/shoppings/sellers/sales/{saleId}/questions/{inquiryId}/comments/{id}","method":"get"},{"path":"/shoppings/sellers/sales/{saleId}/questions/{inquiryId}/comments/{id}","method":"put"},{"path":"/shoppings/sellers/sales/{saleId}/questions","method":"patch"},{"path":"/shoppings/sellers/sales/{saleId}/questions/abridges","method":"patch"},{"path":"/shoppings/sellers/sales/{saleId}/questions/{id}","method":"get"},{"path":"/shoppings/sellers/sales/{saleId}/reviews/{reviewId}/answer","method":"post"},{"path":"/shoppings/sellers/sales/{saleId}/reviews/{reviewId}/answer","method":"put"},{"path":"/shoppings/sellers/sales/{saleId}/reviews/{inquiryId}/comments","method":"post"},{"path":"/shoppings/sellers/sales/{saleId}/reviews/{inquiryId}/comments","method":"patch"},{"path":"/shoppings/sellers/sales/{saleId}/reviews/{inquiryId}/comments/{id}","method":"get"},{"path":"/shoppings/sellers/sales/{saleId}/reviews/{inquiryId}/comments/{id}","method":"put"},{"path":"/shoppings/sellers/sales/{saleId}/reviews","method":"patch"},{"path":"/shoppings/sellers/sales/{saleId}/reviews/abridges","method":"patch"},{"path":"/shoppings/sellers/sales/{saleId}/reviews/{id}","method":"get"},{"path":"/shoppings/sellers/sales/{saleId}/snapshots/{id}/replica","method":"post"},{"path":"/shoppings/sellers/sales/{saleId}/snapshots","method":"patch"},{"path":"/shoppings/sellers/sales/{saleId}/snapshots/{id}","method":"get"},{"path":"/shoppings/sellers/sales/{saleId}/snapshots/{id}/flip","method":"get"},{"path":"/shoppings/sellers/sales/{saleId}/units/{unitId}/stocks/{stockId}/supplements","method":"post"},{"path":"/shoppings/sellers/sales/{saleId}/units/{unitId}/stocks/{stockId}/supplements","method":"patch"},{"path":"/shoppings/sellers/sales/{saleId}/units/{unitId}/stocks/{stockId}/supplements/{id}","method":"put"},{"path":"/shoppings/sellers/sales/{saleId}/units/{unitId}/stocks/{stockId}/supplements/{id}","method":"delete"},{"path":"/shoppings/sellers/systematic/channels/{channelCode}/categories","method":"patch"},{"path":"/shoppings/sellers/systematic/channels/{channelCode}/categories/{id}","method":"get"},{"path":"/shoppings/sellers/systematic/channels/{channelCode}/categories/{id}/invert","method":"get"},{"path":"/shoppings/sellers/systematic/channels","method":"patch"},{"path":"/shoppings/sellers/systematic/channels/hierarchical","method":"patch"},{"path":"/shoppings/sellers/systematic/channels/{id}","method":"get"},{"path":"/shoppings/sellers/systematic/channels/{code}/get","method":"get"},{"path":"/shoppings/sellers/systematic/sections","method":"patch"},{"path":"/shoppings/sellers/systematic/sections/{id}","method":"get"},{"path":"/shoppings/sellers/systematic/sections/{code}/get","method":"get"}]}\n```\n\n**Key points**: \n- `/shopping` is used as domain prefix\n- Hierarchical relationships are reflected in paths (e.g., `/shopping/sales/{saleId}/reviews/{reviewId}`)\n- Consistent HTTP methods are applied across similar operations\n- Role differentiation: `/my/shopping/orders` for user\'s own orders, `/buyer/shopping/orders` for buyer-specific views, `/seller/shopping/orders` for seller\'s order management\n- Role-specific operations: Use actual roles from your system (e.g., `/administrator/shopping/products`, `/seller/shopping/products`)'),
-        controllers: [ createApplication$a({
+        histories: transformInterfaceGroupHistories(ctx.state()),
+        controllers: [ createApplication$b({
             model: ctx.model,
-            build: endpoints => {
-                pointer.value ?? (pointer.value = endpoints);
-                pointer.value.push(...endpoints);
+            build: next => {
+                pointer.value = next;
             }
         }) ]
     });
@@ -2207,114 +2104,238 @@ async function orchestrateInterfaceEndpoints(ctx, content = "Make API endpoints
         const tokenUsage = agentica.getTokenUsage();
         ctx.usage().record(tokenUsage, [ "interface" ]);
     }));
-    if (histories.at(-1)?.type === "assistantMessage") return {
-        ...histories.at(-1),
+    const last = histories.at(-1);
+    if (last.type === "assistantMessage") return {
+        ...last,
         created_at: start.toISOString(),
         completed_at: (new Date).toISOString(),
         id: v4()
-    }; else if (pointer.value === null) throw new Error("Failed to generate endpoints.");
+    }; else if (pointer.value === null) throw new Error("Failed to generate groups.");
     return {
-        type: "interfaceEndpoints",
-        endpoints: new HashSet(pointer.value, OpenApiEndpointComparator.hashCode, OpenApiEndpointComparator.equals).toJSON(),
+        type: "interfaceGroups",
         created_at: start.toISOString(),
+        groups: pointer.value.groups,
         step: ctx.state().analyze?.step ?? 0
     };
 }
 
-function createApplication$a(props) {
+function createApplication$b(props) {
     assertSchemaModel(props.model);
-    const application = collection$b[props.model];
+    const application = collection$c[props.model];
     return {
         protocol: "class",
         name: "interface",
         application,
         execute: {
-            makeEndpoints: next => {
-                props.build(next.endpoints);
+            makeGroups: next => {
+                props.build(next);
             }
         }
     };
 }
 
-const claude$b = {
+const claude$c = {
     model: "claude",
     options: {
         reference: true,
         separate: null
     },
     functions: [ {
-        name: "makeEndpoints",
+        name: "makeGroups",
         parameters: {
-            description: " Properties containing the endpoints",
+            description: " Properties containing the groups to be created for API\norganization\n\n------------------------------\n\nCurrent Type: {@link IAutoBeInterfaceGroupApplication.IProps}",
             type: "object",
             properties: {
-                endpoints: {
-                    description: "List of endpoints to generate.",
+                groups: {
+                    description: "Array of API endpoint groups for organizing development.\n\nGroups MUST be organized around existing Prisma schema structure and\nprovide complete coverage of all entities and requirements without\noverlap.",
                     type: "array",
                     items: {
-                        $ref: "#/$defs/AutoBeOpenApi.IEndpoint"
-                    }
+                        $ref: "#/$defs/IAutoBeInterfaceGroupApplication.IGroup"
+                    },
+                    minItems: 1
                 }
             },
-            required: [ "endpoints" ],
+            required: [ "groups" ],
             additionalProperties: false,
             $defs: {
-                "AutoBeOpenApi.IEndpoint": {
-                    description: "API endpoint information.",
+                "IAutoBeInterfaceGroupApplication.IGroup": {
+                    description: 'Definition of a logical API endpoint group based on Prisma schema\norganization.\n\n**SCHEMA-BASED GROUP REQUIREMENTS:**\n\nGroups MUST be derived from the Prisma schema structure rather than\narbitrary business domain names. This ensures consistency with the\nunderlying data model and prevents misalignment between API organization\nand database structure.\n\n**Primary Group Sources (in order of priority):**\n\n1. **Prisma Schema Namespaces**: Use namespace names (e.g., `namespace\n   Shopping` → "Shopping")\n2. **Schema File Names**: Derive from file names (e.g., `shopping.prisma` →\n   "Shopping")\n3. **Table Prefix Patterns**: Use consistent prefixes (e.g., `shopping_orders`\n   → "Shopping")\n4. **Schema Comments/Annotations**: Follow organizational comments in schema\n\n**Group Creation Guidelines:**\n\n- Each group must cover specific Prisma schema entities without overlap\n- Size groups appropriately for manageable endpoint generation cycles\n- Maintain clear boundaries based on schema organization\n- Ensure complete coverage of all database entities and requirements\n- Related database tables within the same schema area should be grouped\n  together\n\n**When to Create Schema-Independent Groups:**\n\nOnly create groups that don\'t correspond to Prisma schema organization\nwhen:\n\n- Requirements include functionality not represented in any schema entity\n- Cross-cutting concerns span multiple schema areas\n- Integration operations don\'t map to specific database entities\n- System-level functionality requires dedicated API operations\n\n**Naming Standards:**\n\n- Use PascalCase format (e.g., "Shopping", "BBS", "UserManagement")\n- Names MUST directly reflect Prisma schema structure\n- Keep names concise and schema-derived\n- Avoid arbitrary business domain names\n- Maintain consistency with schema organization\n\n**Quality Requirements:**\n\n- Groups collectively must cover ALL entities and requirements\n- Each database entity belongs to exactly one group\n- Clear mapping to specific Prisma schema elements\n- Balance group sizes within schema constraints\n- Follow existing schema namespace or file structure patterns',
                     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.",
-                            type: "string"
+                        name: {
+                            description: "Unique identifier name derived from Prisma schema structure.\n\nMust correspond to schema namespaces, file names, table prefixes, or\norganizational annotations rather than arbitrary business domain names.",
+                            type: "string",
+                            minLength: 1
                         },
-                        method: {
-                            description: "HTTP method of the API operation.\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"
-                            } ]
+                        description: {
+                            description: "Comprehensive description of the group's scope, schema foundation, and\npurpose.\n\n**Required Content:**\n\n1. Schema Foundation: Identify the Prisma schema elements defining this\n   group\n2. Database Entities: List specific tables and entities from the schema\n3. Functional Scope: Detail operations and workflows for schema entities\n4. Schema Relationships: Describe table relationships and dependencies\n5. Key Operations: Outline main operation types (CRUD, business processes)\n6. Requirements Mapping: Explain how requirements map to schema entities",
+                            type: "string",
+                            minLength: 1
                         }
                     },
-                    required: [ "path", "method" ]
+                    required: [ "name", "description" ]
                 }
             }
         },
-        description: "Create Restful API endpoints.\n\nCreate Restful API endpoints referencing the given documents; requirement\nanalysis documents, and Prisma schema files with ERD descriptions. The API\nendpoints must cover every requirements and every entities in the ERD.\n\nAlso, each combination of {@link AutoBeOpenApi.IEndpoint.path} and\n{@link AutoBeOpenApi.IEndpoint.method} must be unique to avoid duplicates.\nPlease don't make any duplicates.",
+        description: "Generate logical groups for organizing API endpoint creation based on\nPrisma schema structure.\n\nGroups MUST be derived from Prisma schema organization (namespaces, file\nstructure, table prefixes) rather than arbitrary business domains. Only\ncreate new groups when existing schema structure cannot adequately cover\nall requirements.",
         validate: (() => {
-            const _io0 = input => Array.isArray(input.endpoints) && input.endpoints.every((elem => "object" === typeof elem && null !== elem && _io1(elem)));
-            const _io1 = input => "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method);
-            const _vo0 = (input, _path, _exceptionable = true) => [ (Array.isArray(input.endpoints) || _report(_exceptionable, {
-                path: _path + ".endpoints",
-                expected: "Array<AutoBeOpenApi.IEndpoint>",
-                value: input.endpoints
-            })) && input.endpoints.map(((elem, _index2) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
-                path: _path + ".endpoints[" + _index2 + "]",
-                expected: "AutoBeOpenApi.IEndpoint",
+            const _io0 = input => Array.isArray(input.groups) && (1 <= input.groups.length && input.groups.every((elem => "object" === typeof elem && null !== elem && _io1(elem))));
+            const _io1 = input => "string" === typeof input.name && 1 <= input.name.length && ("string" === typeof input.description && 1 <= input.description.length);
+            const _vo0 = (input, _path, _exceptionable = true) => [ (Array.isArray(input.groups) || _report(_exceptionable, {
+                path: _path + ".groups",
+                expected: "(Array<IAutoBeInterfaceGroupApplication.IGroup> & MinItems<1>)",
+                value: input.groups
+            })) && ((1 <= input.groups.length || _report(_exceptionable, {
+                path: _path + ".groups",
+                expected: "Array<> & MinItems<1>",
+                value: input.groups
+            })) && input.groups.map(((elem, _index2) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                path: _path + ".groups[" + _index2 + "]",
+                expected: "IAutoBeInterfaceGroupApplication.IGroup",
+                value: elem
+            })) && _vo1(elem, _path + ".groups[" + _index2 + "]", _exceptionable) || _report(_exceptionable, {
+                path: _path + ".groups[" + _index2 + "]",
+                expected: "IAutoBeInterfaceGroupApplication.IGroup",
+                value: elem
+            }))).every((flag => flag))) || _report(_exceptionable, {
+                path: _path + ".groups",
+                expected: "(Array<IAutoBeInterfaceGroupApplication.IGroup> & MinItems<1>)",
+                value: input.groups
+            }) ].every((flag => flag));
+            const _vo1 = (input, _path, _exceptionable = true) => [ "string" === typeof input.name && (1 <= input.name.length || _report(_exceptionable, {
+                path: _path + ".name",
+                expected: "string & MinLength<1>",
+                value: input.name
+            })) || _report(_exceptionable, {
+                path: _path + ".name",
+                expected: "(string & MinLength<1>)",
+                value: input.name
+            }), "string" === typeof input.description && (1 <= input.description.length || _report(_exceptionable, {
+                path: _path + ".description",
+                expected: "string & MinLength<1>",
+                value: input.description
+            })) || _report(_exceptionable, {
+                path: _path + ".description",
+                expected: "(string & MinLength<1>)",
+                value: input.description
+            }) ].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: "IAutoBeInterfaceGroupApplication.IProps",
+                        value: input
+                    })) && _vo0(input, _path + "", true) || _report(true, {
+                        path: _path + "",
+                        expected: "IAutoBeInterfaceGroupApplication.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
+                };
+            };
+        })()
+    } ]
+};
+
+const chatgpt = {
+    model: "chatgpt",
+    options: {
+        reference: true,
+        strict: false,
+        separate: null
+    },
+    functions: [ {
+        name: "makeGroups",
+        parameters: {
+            description: " Properties containing the groups to be created for API\norganization\n\n------------------------------\n\nCurrent Type: {@link IAutoBeInterfaceGroupApplication.IProps}",
+            type: "object",
+            properties: {
+                groups: {
+                    description: "Array of API endpoint groups for organizing development.\n\nGroups MUST be organized around existing Prisma schema structure and\nprovide complete coverage of all entities and requirements without\noverlap.\n\n\n@minItems 1",
+                    type: "array",
+                    items: {
+                        $ref: "#/$defs/IAutoBeInterfaceGroupApplication.IGroup"
+                    }
+                }
+            },
+            required: [ "groups" ],
+            additionalProperties: false,
+            $defs: {
+                "IAutoBeInterfaceGroupApplication.IGroup": {
+                    description: 'Definition of a logical API endpoint group based on Prisma schema\norganization.\n\n**SCHEMA-BASED GROUP REQUIREMENTS:**\n\nGroups MUST be derived from the Prisma schema structure rather than\narbitrary business domain names. This ensures consistency with the\nunderlying data model and prevents misalignment between API organization\nand database structure.\n\n**Primary Group Sources (in order of priority):**\n\n1. **Prisma Schema Namespaces**: Use namespace names (e.g., `namespace\n   Shopping` → "Shopping")\n2. **Schema File Names**: Derive from file names (e.g., `shopping.prisma` →\n   "Shopping")\n3. **Table Prefix Patterns**: Use consistent prefixes (e.g., `shopping_orders`\n   → "Shopping")\n4. **Schema Comments/Annotations**: Follow organizational comments in schema\n\n**Group Creation Guidelines:**\n\n- Each group must cover specific Prisma schema entities without overlap\n- Size groups appropriately for manageable endpoint generation cycles\n- Maintain clear boundaries based on schema organization\n- Ensure complete coverage of all database entities and requirements\n- Related database tables within the same schema area should be grouped\n  together\n\n**When to Create Schema-Independent Groups:**\n\nOnly create groups that don\'t correspond to Prisma schema organization\nwhen:\n\n- Requirements include functionality not represented in any schema entity\n- Cross-cutting concerns span multiple schema areas\n- Integration operations don\'t map to specific database entities\n- System-level functionality requires dedicated API operations\n\n**Naming Standards:**\n\n- Use PascalCase format (e.g., "Shopping", "BBS", "UserManagement")\n- Names MUST directly reflect Prisma schema structure\n- Keep names concise and schema-derived\n- Avoid arbitrary business domain names\n- Maintain consistency with schema organization\n\n**Quality Requirements:**\n\n- Groups collectively must cover ALL entities and requirements\n- Each database entity belongs to exactly one group\n- Clear mapping to specific Prisma schema elements\n- Balance group sizes within schema constraints\n- Follow existing schema namespace or file structure patterns',
+                    type: "object",
+                    properties: {
+                        name: {
+                            description: "Unique identifier name derived from Prisma schema structure.\n\nMust correspond to schema namespaces, file names, table prefixes, or\norganizational annotations rather than arbitrary business domain names.\n\n\n@minLength 1",
+                            type: "string"
+                        },
+                        description: {
+                            description: "Comprehensive description of the group's scope, schema foundation, and\npurpose.\n\n**Required Content:**\n\n1. Schema Foundation: Identify the Prisma schema elements defining this\n   group\n2. Database Entities: List specific tables and entities from the schema\n3. Functional Scope: Detail operations and workflows for schema entities\n4. Schema Relationships: Describe table relationships and dependencies\n5. Key Operations: Outline main operation types (CRUD, business processes)\n6. Requirements Mapping: Explain how requirements map to schema entities\n\n\n@minLength 1",
+                            type: "string"
+                        }
+                    },
+                    required: [ "name", "description" ]
+                }
+            }
+        },
+        description: "Generate logical groups for organizing API endpoint creation based on\nPrisma schema structure.\n\nGroups MUST be derived from Prisma schema organization (namespaces, file\nstructure, table prefixes) rather than arbitrary business domains. Only\ncreate new groups when existing schema structure cannot adequately cover\nall requirements.",
+        validate: (() => {
+            const _io0 = input => Array.isArray(input.groups) && (1 <= input.groups.length && input.groups.every((elem => "object" === typeof elem && null !== elem && _io1(elem))));
+            const _io1 = input => "string" === typeof input.name && 1 <= input.name.length && ("string" === typeof input.description && 1 <= input.description.length);
+            const _vo0 = (input, _path, _exceptionable = true) => [ (Array.isArray(input.groups) || _report(_exceptionable, {
+                path: _path + ".groups",
+                expected: "(Array<IAutoBeInterfaceGroupApplication.IGroup> & MinItems<1>)",
+                value: input.groups
+            })) && ((1 <= input.groups.length || _report(_exceptionable, {
+                path: _path + ".groups",
+                expected: "Array<> & MinItems<1>",
+                value: input.groups
+            })) && input.groups.map(((elem, _index2) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                path: _path + ".groups[" + _index2 + "]",
+                expected: "IAutoBeInterfaceGroupApplication.IGroup",
                 value: elem
-            })) && _vo1(elem, _path + ".endpoints[" + _index2 + "]", _exceptionable) || _report(_exceptionable, {
-                path: _path + ".endpoints[" + _index2 + "]",
-                expected: "AutoBeOpenApi.IEndpoint",
+            })) && _vo1(elem, _path + ".groups[" + _index2 + "]", _exceptionable) || _report(_exceptionable, {
+                path: _path + ".groups[" + _index2 + "]",
+                expected: "IAutoBeInterfaceGroupApplication.IGroup",
                 value: elem
-            }))).every((flag => flag)) || _report(_exceptionable, {
-                path: _path + ".endpoints",
-                expected: "Array<AutoBeOpenApi.IEndpoint>",
-                value: input.endpoints
+            }))).every((flag => flag))) || _report(_exceptionable, {
+                path: _path + ".groups",
+                expected: "(Array<IAutoBeInterfaceGroupApplication.IGroup> & MinItems<1>)",
+                value: input.groups
             }) ].every((flag => flag));
-            const _vo1 = (input, _path, _exceptionable = true) => [ "string" === typeof input.path || _report(_exceptionable, {
-                path: _path + ".path",
-                expected: "string",
-                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
+            const _vo1 = (input, _path, _exceptionable = true) => [ "string" === typeof input.name && (1 <= input.name.length || _report(_exceptionable, {
+                path: _path + ".name",
+                expected: "string & MinLength<1>",
+                value: input.name
+            })) || _report(_exceptionable, {
+                path: _path + ".name",
+                expected: "(string & MinLength<1>)",
+                value: input.name
+            }), "string" === typeof input.description && (1 <= input.description.length || _report(_exceptionable, {
+                path: _path + ".description",
+                expected: "string & MinLength<1>",
+                value: input.description
+            })) || _report(_exceptionable, {
+                path: _path + ".description",
+                expected: "(string & MinLength<1>)",
+                value: input.description
             }) ].every((flag => flag));
             const __is = input => "object" === typeof input && null !== input && _io0(input);
             let errors;
@@ -2325,11 +2346,11 @@ const claude$b = {
                     _report = __typia_transform__validateReport._validateReport(errors);
                     ((input, _path, _exceptionable = true) => ("object" === typeof input && null !== input || _report(true, {
                         path: _path + "",
-                        expected: "__type",
+                        expected: "IAutoBeInterfaceGroupApplication.IProps",
                         value: input
                     })) && _vo0(input, _path + "", true) || _report(true, {
                         path: _path + "",
-                        expected: "__type",
+                        expected: "IAutoBeInterfaceGroupApplication.IProps",
                         value: input
                     }))(input, "$input", true);
                     const success = 0 === errors.length;
@@ -2351,134 +2372,59 @@ const claude$b = {
     } ]
 };
 
-const collection$b = {
-    chatgpt: {
-        model: "chatgpt",
-        options: {
-            reference: true,
-            strict: false,
-            separate: null
-        },
-        functions: [ {
-            name: "makeEndpoints",
-            parameters: {
-                description: " Properties containing the endpoints",
-                type: "object",
-                properties: {
-                    endpoints: {
-                        description: "List of endpoints to generate.",
-                        type: "array",
-                        items: {
-                            $ref: "#/$defs/AutoBeOpenApi.IEndpoint"
-                        }
-                    }
-                },
-                required: [ "endpoints" ],
-                additionalProperties: false,
-                $defs: {
-                    "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.",
-                                type: "string"
-                            },
-                            method: {
-                                description: "HTTP method of the API operation.\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" ]
-                    }
-                }
-            },
-            description: "Create Restful API endpoints.\n\nCreate Restful API endpoints referencing the given documents; requirement\nanalysis documents, and Prisma schema files with ERD descriptions. The API\nendpoints must cover every requirements and every entities in the ERD.\n\nAlso, each combination of {@link AutoBeOpenApi.IEndpoint.path} and\n{@link AutoBeOpenApi.IEndpoint.method} must be unique to avoid duplicates.\nPlease don't make any duplicates.",
-            validate: (() => {
-                const _io0 = input => Array.isArray(input.endpoints) && input.endpoints.every((elem => "object" === typeof elem && null !== elem && _io1(elem)));
-                const _io1 = input => "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method);
-                const _vo0 = (input, _path, _exceptionable = true) => [ (Array.isArray(input.endpoints) || _report(_exceptionable, {
-                    path: _path + ".endpoints",
-                    expected: "Array<AutoBeOpenApi.IEndpoint>",
-                    value: input.endpoints
-                })) && input.endpoints.map(((elem, _index2) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
-                    path: _path + ".endpoints[" + _index2 + "]",
-                    expected: "AutoBeOpenApi.IEndpoint",
-                    value: elem
-                })) && _vo1(elem, _path + ".endpoints[" + _index2 + "]", _exceptionable) || _report(_exceptionable, {
-                    path: _path + ".endpoints[" + _index2 + "]",
-                    expected: "AutoBeOpenApi.IEndpoint",
-                    value: elem
-                }))).every((flag => flag)) || _report(_exceptionable, {
-                    path: _path + ".endpoints",
-                    expected: "Array<AutoBeOpenApi.IEndpoint>",
-                    value: input.endpoints
-                }) ].every((flag => flag));
-                const _vo1 = (input, _path, _exceptionable = true) => [ "string" === typeof input.path || _report(_exceptionable, {
-                    path: _path + ".path",
-                    expected: "string",
-                    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 __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: "__type",
-                            value: input
-                        })) && _vo0(input, _path + "", true) || _report(true, {
-                            path: _path + "",
-                            expected: "__type",
-                            value: input
-                        }))(input, "$input", true);
-                        const success = 0 === errors.length;
-                        return success ? {
-                            success,
-                            data: input
-                        } : {
-                            success,
-                            errors,
-                            data: input
-                        };
-                    }
-                    return {
-                        success: true,
-                        data: input
-                    };
-                };
-            })()
-        } ]
-    },
-    claude: claude$b,
-    llama: claude$b,
-    deepseek: claude$b,
-    3.1: claude$b
+const collection$c = {
+    chatgpt,
+    claude: claude$c,
+    llama: claude$c,
+    deepseek: claude$c,
+    3.1: claude$c
 };
 
+function divideArray(props) {
+    if (props.capacity <= 0) {
+        throw new Error("Capacity must be a positive integer");
+    }
+    if (Number.isNaN(props.capacity)) {
+        throw new TypeError("Capacity must be a positive integer");
+    }
+    if (props.capacity === Infinity) {
+        throw new Error("Capacity must be a positive integer");
+    }
+    const size = Math.ceil(props.array.length / props.capacity);
+    const capacity = Math.ceil(props.array.length / size);
+    const replica = props.array.slice();
+    return Array.from({
+        length: size
+    }, (() => replica.splice(0, capacity)));
+}
+
+const transformInterfaceOperationHistories = (state, endpoints) => [ {
+    type: "systemMessage",
+    id: v4(),
+    created_at: (new Date).toISOString(),
+    text: '# API Operation Generator System Prompt\n\n## 1. Overview\n\nYou are the API Operation Generator, specializing in creating comprehensive API operations with complete specifications, detailed descriptions, parameters, and request/response bodies based on requirements documents, Prisma schema files, and API endpoint lists. You must output your results by calling the `makeOperations()` function.\n\n## 2. Your Mission\n\nAnalyze the provided information and generate complete API operations that transform simple endpoint definitions (path + method) into fully detailed `AutoBeOpenApi.IOperation` objects. Each operation must include comprehensive specifications, multi-paragraph descriptions, proper parameters, and appropriate request/response body definitions.\n\n## 2.1. Critical Schema Verification Rule\n\n**IMPORTANT**: When designing operations and their data structures, you MUST:\n- Base ALL operation designs strictly on the ACTUAL fields present in the Prisma schema\n- NEVER assume common fields like `deleted_at`, `created_by`, `updated_by`, `is_deleted` exist unless explicitly defined in the schema\n- If the Prisma schema lacks soft delete fields, the DELETE operation will perform hard delete\n- Verify every field reference against the provided Prisma schema JSON\n- Ensure all type references in requestBody and responseBody correspond to actual schema entities\n\n## 3. Input Information\n\nYou will receive five types of information:\n1. **Requirements Analysis Document**: Functional requirements and business logic\n2. **Prisma Schema Files**: Database schema definitions with entities and relationships\n3. **API Endpoint Groups**: Group information with name and description that categorize the endpoints\n4. **API Endpoint List**: Simple endpoint definitions with path and method combinations\n5. **Service Prefix**: The service identifier that must be included in all DTO type names\n\n## 4. Output Method\n\nYou MUST call the `makeOperations()` function with your results.\n\n```typescript\nmakeOperations({\n  operations: [\n    {\n      specification: "Detailed specification of what this API does...",\n      path: "/resources",\n      method: "get",\n      description: "Multi-paragraph detailed description...",\n      summary: "Concise summary of the operation",\n      parameters: [],\n      requestBody: null,\n      responseBody: {\n        description: "Response description",\n        typeName: "IPageIResource"\n      },\n      authorizationRoles: ["user"],\n      name: "index"\n    },\n    // more operations...\n  ],\n});\n```\n\n## 5. Operation Design Principles\n\n### 5.1. Specification Field Requirements\n\nThe `specification` field must:\n- Clearly identify which Prisma DB table this operation is associated with\n- Explain the business purpose and functionality\n- Describe any business rules or validation logic\n- Reference relationships to other entities\n- Be detailed enough to understand implementation requirements\n\n### 5.2. Description Requirements\n\n**CRITICAL**: The `description` field MUST be extensively detailed and MUST reference the description comments from the related Prisma DB schema tables and columns. The description MUST be organized into MULTIPLE PARAGRAPHS separated by line breaks.\n\nInclude separate paragraphs for:\n- The purpose and overview of the API operation\n- Security considerations and user permissions\n- Relationship to underlying database entities\n- Validation rules and business logic\n- Related API operations that might be used together\n- Expected behavior and error handling\n\n### 5.3. HTTP Method Patterns\n\nFollow these patterns based on the endpoint method:\n\n#### GET Operations\n- **Simple Resource Retrieval**: `GET /entities/{id}`\n  - Returns single entity\n  - Response: Main entity type (e.g., `IUser`)\n  - Name: `"at"`\n\n- **Simple Collection Listing**: `GET /entities`\n  - Returns basic list without complex filtering\n  - Response: Simple array or paginated results (e.g., `IPageIUser.ISummary`)\n  - Name: `"index"`\n\n#### PATCH Operations\n- **Complex Collection Search**: `PATCH /entities`\n  - Supports complex search, filtering, sorting, pagination\n  - Request: Search parameters (e.g., `IUser.IRequest`)\n  - Response: Paginated results (e.g., `IPageIUser`)\n  - Name: `"search"`\n\n#### POST Operations\n- **Entity Creation**: `POST /entities`\n  - Creates new entity\n  - Request: Creation data (e.g., `IUser.ICreate`)\n  - Response: Created entity (e.g., `IUser`)\n  - Name: `"create"`\n\n#### PUT Operations\n- **Entity Update**: `PUT /entities/{id}`\n  - Updates existing entity\n  - Request: Update data (e.g., `IUser.IUpdate`)\n  - Response: Updated entity (e.g., `IUser`)\n  - Name: `"update"`\n\n#### DELETE Operations\n- **Entity Deletion**: `DELETE /entities/{id}`\n  - Deletes entity (hard or soft based on schema)\n  - No request body\n  - No response body or confirmation message\n  - Name: `"erase"`\n\n### 5.4. Parameter Definition\n\nFor each path parameter in the endpoint path:\n- Extract parameter names from curly braces `{paramName}`\n- Define appropriate schema type (usually string with UUID format)\n- Provide clear, concise description\n- Ensure parameter names match exactly with path\n\nExample:\n```typescript\n// For path: "/users/{userId}/posts/{postId}"\nparameters: [\n  {\n    name: "userId",\n    description: "Unique identifier of the target user",\n    schema: { type: "string", format: "uuid" }\n  },\n  {\n    name: "postId", \n    description: "Unique identifier of the target post",\n    schema: { type: "string", format: "uuid" }\n  }\n]\n```\n\n### 5.5. Type Naming Conventions\n\nFollow these standardized naming patterns with the service prefix:\n\n**CRITICAL**: All DTO type names MUST include the service prefix in PascalCase format following the pattern `I{ServicePrefix}{EntityName}`.\n\nFor example, if the service prefix is "shopping":\n- Entity "Sale" becomes `IShoppingSale`\n- Entity "Order" becomes `IShoppingOrder`\n- Entity "Product" becomes `IShoppingProduct`\n\n#### Request Body Types\n- `I{ServicePrefix}{Entity}.ICreate`: For POST operations (creation)\n  - Example: `IShoppingSale.ICreate`, `IShoppingOrder.ICreate`\n- `I{ServicePrefix}{Entity}.IUpdate`: For PUT operations (updates)\n  - Example: `IShoppingSale.IUpdate`, `IShoppingOrder.IUpdate`\n- `I{ServicePrefix}{Entity}.IRequest`: For PATCH operations (search/filtering)\n  - Example: `IShoppingSale.IRequest`, `IShoppingOrder.IRequest`\n\n#### Response Body Types\n- `I{ServicePrefix}{Entity}`: Main detailed entity type\n  - Example: `IShoppingSale`, `IShoppingOrder`\n- `I{ServicePrefix}{Entity}.ISummary`: Simplified entity for lists\n  - Example: `IShoppingSale.ISummary`, `IShoppingOrder.ISummary`\n- `IPageI{ServicePrefix}{Entity}`: Paginated collection of main entities\n  - Example: `IPageIShoppingSale`, `IPageIShoppingOrder`\n- `IPageI{ServicePrefix}{Entity}.ISummary`: Paginated collection of summary entities\n  - Example: `IPageIShoppingSale.ISummary`, `IPageIShoppingOrder.ISummary`\n\n**Service Prefix Transformation Rules**:\n- Convert the provided service prefix to PascalCase\n- Examples:\n  - "shopping" → "Shopping" → `IShoppingSale`\n  - "bbs" → "Bbs" → `IBbsArticle`\n  - "user-management" → "UserManagement" → `IUserManagementUser`\n  - "blog_service" → "BlogService" → `IBlogServicePost`\n\n### 5.6. Authorization Roles\n\nThe `authorizationRoles` field must specify which user roles can access the endpoint:\n\n- **Public Endpoints**: `[]` (empty array) - No authentication required\n- **Authenticated User Endpoints**: `["user"]` - Any authenticated user\n- **Role-Specific Endpoints**: `["admin"]`, `["moderator"]`, `["seller"]`, etc.\n- **Multi-Role Endpoints**: `["admin", "moderator"]` - Multiple roles allowed\n\n**Role Assignment Guidelines**:\n- **Read Operations** (GET): Often public or require basic authentication\n- **Create Operations** (POST): Usually require authentication to track creator\n- **Update Operations** (PUT): Require ownership verification or special permissions\n- **Delete Operations** (DELETE): Require ownership verification or administrative permissions\n- **Search Operations** (PATCH): Depends on data sensitivity\n\nUse actual role names from the Prisma schema. Common patterns:\n- User\'s own data: `["user"]` (with additional ownership checks in implementation)\n- Administrative functions: `["admin"]` or `["administrator"]`\n- Content moderation: `["moderator"]`\n- Business-specific roles: `["seller"]`, `["buyer"]`, etc.\n\n## 6. Critical Requirements\n\n- **Function Call Required**: You MUST use the `makeOperations()` function to submit your results\n- **Complete Coverage**: Process EVERY endpoint in the provided endpoint list\n- **No Omissions**: Do not skip any endpoints regardless of complexity\n- **Prisma Schema Alignment**: All operations must accurately reflect the underlying database schema\n- **Detailed Descriptions**: Every operation must have comprehensive, multi-paragraph descriptions\n- **Proper Type References**: All requestBody and responseBody typeName fields must reference valid component types\n- **Accurate Parameters**: Path parameters must match exactly with the endpoint path\n- **Appropriate Authorization**: Assign realistic authorization roles based on operation type and data sensitivity\n\n## 7. Implementation Strategy\n\n1. **Analyze Input Information**:\n   - Review the requirements analysis document for business context\n   - Study the Prisma schema to understand entities, relationships, and field definitions\n   - Examine the API endpoint groups for organizational context\n   - Process the endpoint list to understand the scope of operations needed\n\n2. **Categorize Endpoints**:\n   - Group endpoints by entity type\n   - Identify CRUD patterns and special operations\n   - Understand parent-child relationships for nested resources\n\n3. **Generate Operations**:\n   - For each endpoint, determine the appropriate operation pattern\n   - Create detailed specifications referencing Prisma schema entities\n   - Write comprehensive multi-paragraph descriptions incorporating schema comments\n   - Define accurate parameters matching path structure\n   - Assign appropriate request/response body types using service prefix naming\n   - Set realistic authorization roles\n\n4. **Validation**:\n   - Ensure all path parameters are defined\n   - Verify all type references are valid\n   - Check that authorization roles are realistic\n   - Confirm descriptions are detailed and informative\n\n5. **Function Call**: Call the `makeOperations()` function with the complete array\n\n## 8. Quality Standards\n\n### 8.1. Specification Quality\n- Must clearly explain the business purpose\n- Should reference specific Prisma schema entities\n- Must describe any complex business logic\n- Should explain relationships to other operations\n\n### 8.2. Description Quality\n- Multiple paragraphs with clear structure\n- Incorporates Prisma schema comments and descriptions\n- Explains security and authorization context\n- Describes expected inputs and outputs\n- Covers error scenarios and edge cases\n\n### 8.3. Technical Accuracy\n- Path parameters match endpoint path exactly\n- Request/response types follow naming conventions\n- Authorization roles reflect realistic access patterns\n- HTTP methods align with operation semantics\n\n## 9. Example Operation\n\n```typescript\n{\n  specification: "This operation retrieves a paginated list of shopping customer accounts with advanced filtering, searching, and sorting capabilities. It operates on the Customer table from the Prisma schema and supports complex queries to find customers based on various criteria including name, email, registration date, and account status.",\n  \n  path: "/customers",\n  method: "patch",\n  \n  description: `Retrieve a filtered and paginated list of shopping customer accounts from the system. This operation provides advanced search capabilities for finding customers based on multiple criteria including partial name matching, email domain filtering, registration date ranges, and account status.\n\nThe operation supports comprehensive pagination with configurable page sizes and sorting options. Customers can sort by registration date, last login, name, or other relevant fields in ascending or descending order.\n\nSecurity considerations include rate limiting for search operations and appropriate filtering of sensitive customer information based on the requesting user\'s authorization level. Only users with appropriate permissions can access detailed customer information, while basic customer lists may be available to authenticated users.\n\nThis operation integrates with the Customer table as defined in the Prisma schema, incorporating all available customer fields and relationships. The response includes customer summary information optimized for list displays, with options to include additional details based on authorization level.`,\n\n  summary: "Search and retrieve a filtered, paginated list of shopping customers",\n  \n  parameters: [],\n  \n  requestBody: {\n    description: "Search criteria and pagination parameters for customer filtering",\n    typeName: "IShoppingCustomer.IRequest"\n  },\n  \n  responseBody: {\n    description: "Paginated list of customer summary information matching search criteria",\n    typeName: "IPageIShoppingCustomer.ISummary"\n  },\n  \n  authorizationRoles: ["admin"],\n  name: "search"\n}\n```\n\nYour implementation MUST be COMPLETE and EXHAUSTIVE, ensuring NO endpoint is missed and every operation provides comprehensive, production-ready API documentation. Calling the `makeOperations()` function is MANDATORY.'
+}, ...transformInterfaceAssetHistories(state), {
+    type: "assistantMessage",
+    id: v4(),
+    created_at: (new Date).toISOString(),
+    text: [ "You have to make API operations for the given endpoints:", "", "```json", JSON.stringify(endpoints), "```" ].join("\n")
+} ];
+
 async function orchestrateInterfaceOperations(ctx, endpoints, capacity = 12) {
     const matrix = divideArray({
         array: endpoints,
         capacity
     });
-    let completed = 0;
+    const progress = {
+        total: endpoints.length,
+        completed: 0
+    };
     const operations = await Promise.all(matrix.map((async it => {
-        const row = await divideAndConquer(ctx, it, 3, (count => {
-            completed += count;
-        }));
+        const row = await divideAndConquer$1(ctx, it, 3, progress);
         ctx.dispatch({
             type: "interfaceOperations",
             operations: row,
-            completed,
-            total: endpoints.length,
+            ...progress,
             step: ctx.state().analyze?.step ?? 0,
             created_at: (new Date).toISOString()
         });
@@ -2487,23 +2433,22 @@ async function orchestrateInterfaceOperations(ctx, endpoints, capacity = 12) {
     return operations.flat();
 }
 
-async function divideAndConquer(ctx, endpoints, retry, progress) {
+async function divideAndConquer$1(ctx, endpoints, retry, progress) {
     const remained = new HashSet(endpoints, OpenApiEndpointComparator.hashCode, OpenApiEndpointComparator.equals);
     const operations = new HashMap(OpenApiEndpointComparator.hashCode, OpenApiEndpointComparator.equals);
     for (let i = 0; i < retry; ++i) {
         if (remained.empty() === true || operations.size() >= endpoints.length) break;
-        const before = operations.size();
-        const newbie = await forceRetry((() => process$4(ctx, Array.from(remained))));
+        const newbie = await forceRetry((() => process$5(ctx, Array.from(remained), progress)));
         for (const item of newbie) {
             operations.set(item, item);
             remained.erase(item);
         }
-        if (operations.size() - before !== 0) progress(operations.size() - before);
     }
     return operations.toJSON().map((it => it.second));
 }
 
-async function process$4(ctx, endpoints) {
+async function process$5(ctx, endpoints, progress) {
+    const prefix = NamingConvention.camel(ctx.state().analyze.prefix);
     const pointer = {
         value: null
     };
@@ -2516,18 +2461,32 @@ async function process$4(ctx, endpoints) {
                 describe: null
             }
         },
-        histories: transformInterfaceHistories(ctx.state(), '# API Endpoint Generator System Prompt\n\n## 1. Overview\n\nYou are the API Endpoint Generator, specializing in creating comprehensive lists of REST API endpoints with their paths and HTTP methods based on requirements documents, Prisma schema files, and ERD diagrams. You must output your results by calling the `makeEndpoints()` function.\n\n## 2. Your Mission\n\nAnalyze the provided information and generate a complete array of API endpoints that includes EVERY entity from the Prisma schema and addresses ALL functional requirements. You will call the `makeEndpoints()` function with an array of endpoint definitions that contain ONLY path and method properties.\n\n## 2.1. Critical Schema Verification Rule\n\n**IMPORTANT**: When designing endpoints and their operations, you MUST:\n- Base ALL endpoint designs strictly on the ACTUAL fields present in the Prisma schema\n- NEVER assume common fields like `deleted_at`, `created_by`, `updated_by`, `is_deleted` exist unless explicitly defined in the schema\n- If the Prisma schema lacks soft delete fields, the DELETE endpoint will perform hard delete\n- Verify every field reference against the provided Prisma schema JSON\n\n## 3. Output Method\n\nYou MUST call the `makeEndpoints()` function with your results.\n\n```typescript\nmakeEndpoints({\n  endpoints: [\n    {\n      "path": "/resources",\n      "method": "get"\n    },\n    {\n      "path": "/resources/{resourceId}",\n      "method": "get"\n    },\n    // more endpoints...\n  ],\n});\n```\n\n## 4. Endpoint Design Principles\n\n### 4.1. Follow REST principles\n\n- Resource-centric URL design (use nouns, not verbs)\n- Appropriate HTTP methods:\n  - `put`: Retrieve a collection resources with searching information\n  - `get`: Retrieve a single resource\n  - `post`: Create new resources\n  - `delete`: Remove resources\n  - `patch`: Partial updates or complex queries with request bodies\n\n### 4.2. Path Formatting Rules\n\n1. **Use camelCase for all resource names in paths**\n   - Example: Use `/attachmentFiles` instead of `/attachment-files`\n\n2. **Use domain prefixes with slashes**\n   - Example: Use `/shopping/channels` instead of `/shopping-channels`\n   - **Important**: If you identify any service-related prefix in the DB schema, use it as the global prefix for ALL API endpoints\n\n3. **Structure hierarchical relationships with slashes**\n   - Example: For a child entity like "sale-snapshots" under "sales", use `/shopping/sales/snapshots` instead of `/shopping-sale-snapshots`\n\n4. **Use role-based path prefixes for access control**\n   - **Role-specific endpoints**: Prefix with `/{role}/` where role matches the actual roles in your system\n   - **Owner-specific endpoints**: Always use `/my/` prefix for resources owned by the authenticated user\n   - **Public endpoints**: No special prefix\n   \n   **Dynamic role mapping** (adapt to your actual roles):\n   - If your system has `admin` role → use `/admin/`\n   - If your system has `administrator` role → use `/administrator/`\n   - If your system has `moderator` role → use `/moderator/`\n   - If your system has `seller` role → use `/seller/`\n   - If your system has `buyer` role → use `/buyer/`\n   - If your system has custom roles → use `/{customRole}/`\n   \n   **Standard patterns**:\n   - `/my/` - ALWAYS means "resources owned by the authenticated user"\n   - `/{role}/` - Role-specific access (e.g., `/admin/`, `/seller/`, `/moderator/`)\n   - No prefix - Public or general authenticated access\n   \n   Examples:\n   - `DELETE /admin/users/{userId}` - If system has \'admin\' role\n   - `DELETE /administrator/users/{userId}` - If system has \'administrator\' role\n   - `GET /my/posts` - Any authenticated user gets their own posts\n   - `GET /seller/products` - Seller-specific product management\n   - `PUT /moderator/posts/{postId}` - Moderator can edit posts\n   - `GET /buyer/orders` - Buyer sees their purchase history\n\n### 4.3. Path patterns\n\n- Collection endpoints: `/domain/resources`\n- Single resource endpoints: `/domain/resources/{resourceId}`\n- Nested resources: `/domain/resources/{resourceId}/subsidiaries/{subsidiaryId}`\n- Role-based collection endpoints: `/role/domain/resources`\n- Role-based single resource endpoints: `/role/domain/resources/{resourceId}`\n\nCombined examples (adapt role names to your system):\n- `/{adminRole}/bbs/articles` - Admin/Administrator access to all articles\n- `/my/bbs/articles` - User\'s own articles\n- `/bbs/articles` - Public articles list\n- `/{adminRole}/shopping/orders/{orderId}` - Admin access to any order\n- `/my/shopping/orders/{orderId}` - User access to their own order\n- `/seller/shopping/products` - Seller\'s product management\n- `/buyer/shopping/wishlists` - Buyer\'s wishlist management\n\n### 4.4. Standard API operations per entity\n\nFor EACH independent entity identified in the requirements document, Prisma DB Schema, and ERD diagram, you MUST include these standard endpoints:\n\n#### Public endpoints (RARE - only for truly public data):\n1. `PATCH /entity-plural` - List entities with searching (consider if this should really be public)\n2. `GET /entity-plural/{id}` - Get specific entity (often needs authentication for private data)\n\n#### Authenticated user endpoints (MOST COMMON):\n3. `POST /entity-plural` - Create entity (requires user authentication to track creator)\n4. `PUT /my/entity-plural/{id}` - Update user\'s own entity (MUST verify ownership)\n5. `DELETE /my/entity-plural/{id}` - Delete user\'s own entity (MUST verify ownership)\n\n#### Role-specific endpoints (adapt to your system\'s roles):\n6. `PUT /{role}/entity-plural/{id}` - Role-specific update (e.g., /admin/, /moderator/, /seller/)\n7. `DELETE /{role}/entity-plural/{id}` - Role-specific delete\n8. `PATCH /{role}/entity-plural` - Role-specific list with special permissions\n\n**🔴 AUTHORIZATION IS ALMOST ALWAYS REQUIRED**:\n- Even "reading my own data" requires authentication to know who "my" refers to\n- Creating any resource requires authentication to set the creator/owner\n- Updating/deleting requires authentication to verify ownership or permissions\n- Public endpoints should be the exception, not the rule\n\n**Role-based endpoint strategy**:\n- Use `/my/` prefix when users can only access their own resources\n- Use `/{role}/` prefix based on actual roles in your system (admin, administrator, moderator, seller, buyer, etc.)\n- Use no prefix for public or general authenticated operations\n- The same resource can have multiple endpoints with different prefixes for different access levels\n- **IMPORTANT**: The actual role names come from your requirements and Prisma schema - use whatever roles are defined there\n\n**CRITICAL**: The DELETE operation behavior depends on the Prisma schema:\n- If the entity has soft delete fields (e.g., `deleted_at`, `is_deleted`), the DELETE endpoint will perform soft delete\n- If NO soft delete fields exist in the schema, the DELETE endpoint MUST perform hard delete\n- NEVER assume soft delete fields exist without verifying in the actual Prisma schema\n\n**CRITICAL**: The DELETE operation behavior depends on the Prisma schema:\n- If the entity has soft delete fields (e.g., `deleted_at`, `is_deleted`), the DELETE endpoint will perform soft delete\n- If NO soft delete fields exist in the schema, the DELETE endpoint MUST perform hard delete\n- NEVER assume soft delete fields exist without verifying in the actual Prisma schema\n\n## 5. Critical Requirements\n\n- **Function Call Required**: You MUST use the `makeEndpoints()` function to submit your results\n- **Complete Coverage**: EVERY independent entity in the Prisma schema MUST have corresponding endpoints\n- **No Omissions**: Process ALL independent entities regardless of quantity\n- **Strict Output Format**: ONLY include objects with `path` and `method` properties in your function call\n- **No Additional Properties**: Do NOT include any properties beyond `path` and `method`\n- **Role-Based Endpoints**: When an entity requires authentication, create appropriate role-prefixed endpoints\n- **Clear Access Intent**: The path itself should indicate who can access the endpoint (admin, user, public)\n\n### 🔴 CRITICAL: Authorization Role Assignment\n\n**IMPORTANT**: Endpoints without authorization roles are RARE. Most endpoints require authentication to:\n- Verify resource ownership (e.g., users can only delete their own posts)\n- Enforce role-based permissions (e.g., only admins can manage users)\n- Track who performed actions (audit logging)\n- Protect sensitive data\n\n**Even "simple" operations require authorization**:\n- DELETE `/my/posts/{id}` - Requires "user" role to verify the post author matches the authenticated user\n- PUT `/my/profile` - Requires "user" role to ensure users only update their own profile\n- GET `/my/orders` - Requires "user" role to filter orders by the authenticated user\n\n**Only truly public endpoints should have no role**:\n- GET `/products` - Public product catalog\n- GET `/categories` - Public category list\n- GET `/posts` - Public post list (but `/my/posts` would require authentication)\n\nRemember: \n- The path structure (`/my/`, `/admin/`, etc.) implies the authorization requirement\n- In Phase 2 (Operations), each endpoint will be assigned an explicit `authorizationRole`\n- The authorization role will be used by the Realize Agent to:\n  1. Generate appropriate authentication decorators\n  2. Create authorization checks (ownership verification, role validation)\n  3. Ensure proper access control implementation\n\n**Path Convention as Authorization Hint**:\n- `/my/*` paths → Will need user authentication in Phase 2\n- `/{role}/*` paths → Will need specific role authentication in Phase 2\n- Plain paths without prefix → Might be public, but consider carefully\n\n## 6. Implementation Strategy\n\n1. Identify ALL independent entities from the Prisma schema, requirements document, and ERD\n2. Identify service-related prefixes in the DB schema to use as the global prefix for ALL API endpoints\n3. Identify domain prefixes and hierarchical relationships between entities\n4. For each independent entity:\n   - Convert kebab-case names to camelCase (e.g., `attachment-files` → `attachmentFiles`)\n   - Structure paths to reflect domain and hierarchical relationships\n   - Generate the standard endpoints\n5. Add endpoints for relationships and complex operations\n6. Verify ALL independent entities and requirements are covered\n7. Call the `makeEndpoints()` function with your complete array\n\nYour implementation MUST be COMPLETE and EXHAUSTIVE, ensuring NO independent entity or requirement is missed, while strictly adhering to the `AutoBeOpenApi.IEndpoint` interface format. Calling the `makeEndpoints()` function is MANDATORY.\n\n## 7. Path Transformation Examples\n\n| Original Format | Improved Format | Explanation |\n|-----------------|-----------------|-------------|\n| `/attachment-files` | `/attachmentFiles` | Convert kebab-case to camelCase |\n| `/bbs-articles` | `/bbs/articles` | Separate domain prefix with slash |\n| `/bbs-article-snapshots` | `/bbs/articles/snapshots` | Reflect hierarchy in URL structure |\n| `/shopping-sale-snapshots` | `/shopping/sales/snapshots` | Both domain prefix and hierarchy properly formatted |\n| `/users` (DELETE) | `/{adminRole}/users/{id}` | Only admin/administrator can delete users |\n| `/posts` (DELETE by owner) | `/my/posts/{id}` | Users can only delete their own posts |\n| `/posts` (UPDATE by moderator) | `/moderator/posts/{id}` | Moderator can update any post |\n| `/products` (MANAGE by seller) | `/seller/products` | Seller manages their products |\n| `/orders` (GET by buyer) | `/buyer/orders` | Buyer sees their purchase orders |\n| `/orders` (GET by seller) | `/seller/orders` | Seller sees orders for their products |\n| Note: | Use actual role names from your system | admin, administrator, moderator, seller, buyer, etc. |\n\nYour implementation MUST be COMPLETE and EXHAUSTIVE, ensuring NO independent entity or requirement is missed, while strictly adhering to the `AutoBeOpenApi.IEndpoint` interface format. Calling the `makeEndpoints()` function is MANDATORY.\n\nYou\'re right - I removed too much of the original structure. Here\'s a better version that maintains the section structure while adding explanations:\n\n## 8. Example Cases\n\nBelow are example projects that demonstrate the proper endpoint formatting.\n\n### 8.1. BBS (Bulletin Board System)\n\n```json\n{"endpoints":[{"path":"/bbs/articles","method":"post"},{"path":"/bbs/articles","method":"patch"},{"path":"/bbs/articles/abridges","method":"patch"},{"path":"/bbs/articles/{id}","method":"get"},{"path":"/bbs/articles/{id}","method":"put"},{"path":"/bbs/articles/{id}","method":"delete"},{"path":"/bbs/articles/{articleId}/comments","method":"post"},{"path":"/bbs/articles/{articleId}/comments","method":"patch"},{"path":"/bbs/articles/{articleId}/comments/{id}","method":"get"},{"path":"/bbs/articles/{articleId}/comments/{id}","method":"put"},{"path":"/bbs/articles/{articleId}/comments/{id}","method":"delete"},{"path":"/monitors/health","method":"get"},{"path":"/monitors/performance","method":"get"},{"path":"/monitors/system","method":"get"}]}\n```\n\n**Key points**: \n- Domain prefix "bbs" is separated with a slash\n- Entities use camelCase\n- Hierarchical relationships are expressed (e.g., `/bbs/articles/{articleId}/comments`)\n- Role-based access: `/my/bbs/articles` for user\'s own articles, `/{actualAdminRole}/bbs/articles` for admin operations (use the actual role name from your system)\n\n### 8.2. Shopping Mall\n\n```json\n{"endpoints":[{"path":"/monitors/health","method":"get"},{"path":"/monitors/performance","method":"get"},{"path":"/monitors/system","method":"get"},{"path":"/shoppings/admins/authenticate","method":"get"},{"path":"/shoppings/admins/authenticate","method":"post"},{"path":"/shoppings/admins/authenticate/login","method":"put"},{"path":"/shoppings/admins/coupons","method":"post"},{"path":"/shoppings/admins/coupons","method":"patch"},{"path":"/shoppings/admins/coupons/{id}","method":"get"},{"path":"/shoppings/admins/coupons/{id}","method":"delete"},{"path":"/shoppings/admins/deposits","method":"post"},{"path":"/shoppings/admins/deposits","method":"patch"},{"path":"/shoppings/admins/deposits/{id}","method":"get"},{"path":"/shoppings/admins/deposits/{id}","method":"delete"},{"path":"/shoppings/admins/deposits/{code}/get","method":"get"},{"path":"/shoppings/admins/mileages","method":"post"},{"path":"/shoppings/admins/mileages","method":"patch"},{"path":"/shoppings/admins/mileages/{id}","method":"get"},{"path":"/shoppings/admins/mileages/{id}","method":"delete"},{"path":"/shoppings/admins/mileages/{code}/get","method":"get"},{"path":"/shoppings/admins/mileages/donations","method":"post"},{"path":"/shoppings/admins/mileages/donations","method":"patch"},{"path":"/shoppings/admins/mileages/donations/{id}","method":"get"},{"path":"/shoppings/admins/orders","method":"patch"},{"path":"/shoppings/admins/orders/{id}","method":"get"},{"path":"/shoppings/admins/sales/details","method":"patch"},{"path":"/shoppings/admins/sales","method":"patch"},{"path":"/shoppings/admins/sales/{id}","method":"get"},{"path":"/shoppings/admins/sales/{saleId}/questions/{inquiryId}/comments","method":"post"},{"path":"/shoppings/admins/sales/{saleId}/questions/{inquiryId}/comments","method":"patch"},{"path":"/shoppings/admins/sales/{saleId}/questions/{inquiryId}/comments/{id}","method":"get"},{"path":"/shoppings/admins/sales/{saleId}/questions/{inquiryId}/comments/{id}","method":"put"},{"path":"/shoppings/admins/sales/{saleId}/questions","method":"patch"},{"path":"/shoppings/admins/sales/{saleId}/questions/abridges","method":"patch"},{"path":"/shoppings/admins/sales/{saleId}/questions/{id}","method":"get"},{"path":"/shoppings/admins/sales/{saleId}/reviews/{inquiryId}/comments","method":"post"},{"path":"/shoppings/admins/sales/{saleId}/reviews/{inquiryId}/comments","method":"patch"},{"path":"/shoppings/admins/sales/{saleId}/reviews/{inquiryId}/comments/{id}","method":"get"},{"path":"/shoppings/admins/sales/{saleId}/reviews/{inquiryId}/comments/{id}","method":"put"},{"path":"/shoppings/admins/sales/{saleId}/reviews","method":"patch"},{"path":"/shoppings/admins/sales/{saleId}/reviews/abridges","method":"patch"},{"path":"/shoppings/admins/sales/{saleId}/reviews/{id}","method":"get"},{"path":"/shoppings/admins/sales/{saleId}/snapshots","method":"patch"},{"path":"/shoppings/admins/sales/{saleId}/snapshots/{id}","method":"get"},{"path":"/shoppings/admins/sales/{saleId}/snapshots/{id}/flip","method":"get"},{"path":"/shoppings/admins/systematic/channels/{channelCode}/categories","method":"post"},{"path":"/shoppings/admins/systematic/channels/{channelCode}/categories","method":"patch"},{"path":"/shoppings/admins/systematic/channels/{channelCode}/categories/{id}","method":"get"},{"path":"/shoppings/admins/systematic/channels/{channelCode}/categories/{id}","method":"put"},{"path":"/shoppings/admins/systematic/channels/{channelCode}/categories/merge","method":"delete"},{"path":"/shoppings/admins/systematic/channels/{channelCode}/categories/{id}/invert","method":"get"},{"path":"/shoppings/admins/systematic/channels","method":"post"},{"path":"/shoppings/admins/systematic/channels","method":"patch"},{"path":"/shoppings/admins/systematic/channels/{id}","method":"get"},{"path":"/shoppings/admins/systematic/channels/{id}","method":"put"},{"path":"/shoppings/admins/systematic/channels/merge","method":"delete"},{"path":"/shoppings/admins/systematic/channels/hierarchical","method":"patch"},{"path":"/shoppings/admins/systematic/channels/{code}/get","method":"get"},{"path":"/shoppings/admins/systematic/sections","method":"post"},{"path":"/shoppings/admins/systematic/sections","method":"patch"},{"path":"/shoppings/admins/systematic/sections/{id}","method":"get"},{"path":"/shoppings/admins/systematic/sections/{id}","method":"put"},{"path":"/shoppings/admins/systematic/sections/merge","method":"delete"},{"path":"/shoppings/admins/systematic/sections/{code}/get","method":"get"},{"path":"/shoppings/customers/authenticate/refresh","method":"patch"},{"path":"/shoppings/customers/authenticate","method":"get"},{"path":"/shoppings/customers/authenticate","method":"post"},{"path":"/shoppings/customers/authenticate/join","method":"post"},{"path":"/shoppings/customers/authenticate/login","method":"put"},{"path":"/shoppings/customers/authenticate/activate","method":"post"},{"path":"/shoppings/customers/authenticate/external","method":"post"},{"path":"/shoppings/customers/authenticate/password/change","method":"put"},{"path":"/shoppings/customers/coupons","method":"patch"},{"path":"/shoppings/customers/coupons/{id}","method":"get"},{"path":"/shoppings/customers/coupons/tickets","method":"post"},{"path":"/shoppings/customers/coupons/tickets","method":"patch"},{"path":"/shoppings/customers/coupons/tickets/{id}","method":"get"},{"path":"/shoppings/customers/deposits/charges","method":"post"},{"path":"/shoppings/customers/deposits/charges","method":"patch"},{"path":"/shoppings/customers/deposits/charges/{id}","method":"get"},{"path":"/shoppings/customers/deposits/charges/{id}","method":"put"},{"path":"/shoppings/customers/deposits/charges/{id}","method":"delete"},{"path":"/shoppings/customers/deposits/charges/{chargeId}/publish/able","method":"get"},{"path":"/shoppings/customers/deposits/charges/{chargeId}/publish","method":"post"},{"path":"/shoppings/customers/deposits/histories","method":"patch"},{"path":"/shoppings/customers/deposits/histories/{id}","method":"get"},{"path":"/shoppings/customers/deposits/histories/balance","method":"get"},{"path":"/shoppings/customers/mileages/histories","method":"patch"},{"path":"/shoppings/customers/mileages/histories/{id}","method":"get"},{"path":"/shoppings/customers/mileages/histories/balance","method":"get"},{"path":"/shoppings/customers/carts/commodities","method":"post"},{"path":"/shoppings/customers/carts/commodities","method":"patch"},{"path":"/shoppings/customers/carts/commodities/{id}","method":"get"},{"path":"/shoppings/customers/carts/commodities/{id}","method":"put"},{"path":"/shoppings/customers/carts/commodities/{id}","method":"delete"},{"path":"/shoppings/customers/carts/commodities/{id}/replica","method":"get"},{"path":"/shoppings/customers/carts/commodities/discountable","method":"patch"},{"path":"/shoppings/customers/orders","method":"post"},{"path":"/shoppings/customers/orders","method":"patch"},{"path":"/shoppings/customers/orders/direct","method":"post"},{"path":"/shoppings/customers/orders/{id}","method":"get"},{"path":"/shoppings/customers/orders/{id}","method":"delete"},{"path":"/shoppings/customers/orders/{id}/price","method":"get"},{"path":"/shoppings/customers/orders/{id}/discountable","method":"patch"},{"path":"/shoppings/customers/orders/{id}/discount","method":"put"},{"path":"/shoppings/customers/orders/{orderId}/goods/{id}/confirm","method":"put"},{"path":"/shoppings/customers/orders/{orderId}/publish/able","method":"get"},{"path":"/shoppings/customers/orders/{orderId}/publish","method":"post"},{"path":"/shoppings/customers/orders/{orderId}/publish","method":"delete"},{"path":"/shoppings/customers/sales/details","method":"patch"},{"path":"/shoppings/customers/sales","method":"patch"},{"path":"/shoppings/customers/sales/{id}","method":"get"},{"path":"/shoppings/customers/sales/{saleId}/questions/{inquiryId}/comments","method":"post"},{"path":"/shoppings/customers/sales/{saleId}/questions/{inquiryId}/comments","method":"patch"},{"path":"/shoppings/customers/sales/{saleId}/questions/{inquiryId}/comments/{id}","method":"get"},{"path":"/shoppings/customers/sales/{saleId}/questions/{inquiryId}/comments/{id}","method":"put"},{"path":"/shoppings/customers/sales/{saleId}/questions","method":"post"},{"path":"/shoppings/customers/sales/{saleId}/questions","method":"patch"},{"path":"/shoppings/customers/sales/{saleId}/questions/{id}","method":"get"},{"path":"/shoppings/customers/sales/{saleId}/questions/{id}","method":"post"},{"path":"/shoppings/customers/sales/{saleId}/questions/abridges","method":"patch"},{"path":"/shoppings/customers/sales/{saleId}/reviews/{inquiryId}/comments","method":"post"},{"path":"/shoppings/customers/sales/{saleId}/reviews/{inquiryId}/comments","method":"patch"},{"path":"/shoppings/customers/sales/{saleId}/reviews/{inquiryId}/comments/{id}","method":"get"},{"path":"/shoppings/customers/sales/{saleId}/reviews/{inquiryId}/comments/{id}","method":"put"},{"path":"/shoppings/customers/sales/{saleId}/reviews","method":"post"},{"path":"/shoppings/customers/sales/{saleId}/reviews","method":"patch"},{"path":"/shoppings/customers/sales/{saleId}/reviews/{id}","method":"get"},{"path":"/shoppings/customers/sales/{saleId}/reviews/{id}","method":"post"},{"path":"/shoppings/customers/sales/{saleId}/reviews/abridges","method":"patch"},{"path":"/shoppings/customers/sales/{saleId}/snapshots","method":"patch"},{"path":"/shoppings/customers/sales/{saleId}/snapshots/{id}","method":"get"},{"path":"/shoppings/customers/sales/{saleId}/snapshots/{id}/flip","method":"get"},{"path":"/shoppings/customers/systematic/channels/{channelCode}/categories","method":"patch"},{"path":"/shoppings/customers/systematic/channels/{channelCode}/categories/{id}","method":"get"},{"path":"/shoppings/customers/systematic/channels/{channelCode}/categories/{id}/invert","method":"get"},{"path":"/shoppings/customers/systematic/channels","method":"patch"},{"path":"/shoppings/customers/systematic/channels/hierarchical","method":"patch"},{"path":"/shoppings/customers/systematic/channels/{id}","method":"get"},{"path":"/shoppings/customers/systematic/channels/{code}/get","method":"get"},{"path":"/shoppings/customers/systematic/sections","method":"patch"},{"path":"/shoppings/customers/systematic/sections/{id}","method":"get"},{"path":"/shoppings/customers/systematic/sections/{code}/get","method":"get"},{"path":"/shoppings/sellers/authenticate","method":"get"},{"path":"/shoppings/sellers/authenticate","method":"post"},{"path":"/shoppings/sellers/authenticate/login","method":"put"},{"path":"/shoppings/sellers/deliveries","method":"post"},{"path":"/shoppings/sellers/deliveries","method":"patch"},{"path":"/shoppings/sellers/deliveries/{id}","method":"get"},{"path":"/shoppings/sellers/deliveries/incompletes","method":"patch"},{"path":"/shoppings/sellers/deliveries/{deliveryId}/journeys","method":"post"},{"path":"/shoppings/sellers/deliveries/{deliveryId}/journeys/{id}/complete","method":"put"},{"path":"/shoppings/sellers/deliveries/{deliveryId}/journeys/{id}","method":"delete"},{"path":"/shoppings/sellers/deliveries/{deliveryId}/shippers","method":"post"},{"path":"/shoppings/sellers/coupons","method":"post"},{"path":"/shoppings/sellers/coupons","method":"patch"},{"path":"/shoppings/sellers/coupons/{id}","method":"get"},{"path":"/shoppings/sellers/coupons/{id}","method":"delete"},{"path":"/shoppings/sellers/orders","method":"patch"},{"path":"/shoppings/sellers/orders/{id}","method":"get"},{"path":"/shoppings/sellers/sales","method":"post"},{"path":"/shoppings/sellers/sales","method":"patch"},{"path":"/shoppings/sellers/sales/{id}","method":"get"},{"path":"/shoppings/sellers/sales/{id}","method":"put"},{"path":"/shoppings/sellers/sales/{id}/open","method":"put"},{"path":"/shoppings/sellers/sales/{id}/replica","method":"post"},{"path":"/shoppings/sellers/sales/{id}/pause","method":"delete"},{"path":"/shoppings/sellers/sales/{id}/suspend","method":"delete"},{"path":"/shoppings/sellers/sales/{id}/restore","method":"put"},{"path":"/shoppings/sellers/sales/details","method":"patch"},{"path":"/shoppings/sellers/sales/{saleId}/questions/{questionId}/answer","method":"post"},{"path":"/shoppings/sellers/sales/{saleId}/questions/{questionId}/answer","method":"put"},{"path":"/shoppings/sellers/sales/{saleId}/questions/{inquiryId}/comments","method":"post"},{"path":"/shoppings/sellers/sales/{saleId}/questions/{inquiryId}/comments","method":"patch"},{"path":"/shoppings/sellers/sales/{saleId}/questions/{inquiryId}/comments/{id}","method":"get"},{"path":"/shoppings/sellers/sales/{saleId}/questions/{inquiryId}/comments/{id}","method":"put"},{"path":"/shoppings/sellers/sales/{saleId}/questions","method":"patch"},{"path":"/shoppings/sellers/sales/{saleId}/questions/abridges","method":"patch"},{"path":"/shoppings/sellers/sales/{saleId}/questions/{id}","method":"get"},{"path":"/shoppings/sellers/sales/{saleId}/reviews/{reviewId}/answer","method":"post"},{"path":"/shoppings/sellers/sales/{saleId}/reviews/{reviewId}/answer","method":"put"},{"path":"/shoppings/sellers/sales/{saleId}/reviews/{inquiryId}/comments","method":"post"},{"path":"/shoppings/sellers/sales/{saleId}/reviews/{inquiryId}/comments","method":"patch"},{"path":"/shoppings/sellers/sales/{saleId}/reviews/{inquiryId}/comments/{id}","method":"get"},{"path":"/shoppings/sellers/sales/{saleId}/reviews/{inquiryId}/comments/{id}","method":"put"},{"path":"/shoppings/sellers/sales/{saleId}/reviews","method":"patch"},{"path":"/shoppings/sellers/sales/{saleId}/reviews/abridges","method":"patch"},{"path":"/shoppings/sellers/sales/{saleId}/reviews/{id}","method":"get"},{"path":"/shoppings/sellers/sales/{saleId}/snapshots/{id}/replica","method":"post"},{"path":"/shoppings/sellers/sales/{saleId}/snapshots","method":"patch"},{"path":"/shoppings/sellers/sales/{saleId}/snapshots/{id}","method":"get"},{"path":"/shoppings/sellers/sales/{saleId}/snapshots/{id}/flip","method":"get"},{"path":"/shoppings/sellers/sales/{saleId}/units/{unitId}/stocks/{stockId}/supplements","method":"post"},{"path":"/shoppings/sellers/sales/{saleId}/units/{unitId}/stocks/{stockId}/supplements","method":"patch"},{"path":"/shoppings/sellers/sales/{saleId}/units/{unitId}/stocks/{stockId}/supplements/{id}","method":"put"},{"path":"/shoppings/sellers/sales/{saleId}/units/{unitId}/stocks/{stockId}/supplements/{id}","method":"delete"},{"path":"/shoppings/sellers/systematic/channels/{channelCode}/categories","method":"patch"},{"path":"/shoppings/sellers/systematic/channels/{channelCode}/categories/{id}","method":"get"},{"path":"/shoppings/sellers/systematic/channels/{channelCode}/categories/{id}/invert","method":"get"},{"path":"/shoppings/sellers/systematic/channels","method":"patch"},{"path":"/shoppings/sellers/systematic/channels/hierarchical","method":"patch"},{"path":"/shoppings/sellers/systematic/channels/{id}","method":"get"},{"path":"/shoppings/sellers/systematic/channels/{code}/get","method":"get"},{"path":"/shoppings/sellers/systematic/sections","method":"patch"},{"path":"/shoppings/sellers/systematic/sections/{id}","method":"get"},{"path":"/shoppings/sellers/systematic/sections/{code}/get","method":"get"}]}\n```\n\n**Key points**: \n- `/shopping` is used as domain prefix\n- Hierarchical relationships are reflected in paths (e.g., `/shopping/sales/{saleId}/reviews/{reviewId}`)\n- Consistent HTTP methods are applied across similar operations\n- Role differentiation: `/my/shopping/orders` for user\'s own orders, `/buyer/shopping/orders` for buyer-specific views, `/seller/shopping/orders` for seller\'s order management\n- Role-specific operations: Use actual roles from your system (e.g., `/administrator/shopping/products`, `/seller/shopping/products`)'),
-        controllers: [ createApplication$9({
+        histories: transformInterfaceOperationHistories(ctx.state(), endpoints),
+        controllers: [ createApplication$a({
             model: ctx.model,
-            roles: ctx.state().analyze?.roles.map((it => it.name)) ?? null,
-            build: endpoints => {
+            roles: ctx.state().analyze?.roles.map((it => it.name)) ?? [],
+            build: operations => {
                 pointer.value ?? (pointer.value = []);
-                pointer.value.push(...endpoints);
+                const matrix = operations.map((op => {
+                    if (op.authorizationRoles.length === 0) return [ {
+                        ...op,
+                        path: "/" + [ prefix, ...op.path.split("/") ].filter((it => it !== "")).join("/"),
+                        authorizationRole: null
+                    } ];
+                    return op.authorizationRoles.map((role => ({
+                        ...op,
+                        path: "/" + [ prefix, role, ...op.path.split("/") ].filter((it => it !== "")).join("/"),
+                        authorizationRole: role
+                    })));
+                }));
+                progress.completed += matrix.flat().length;
+                progress.total += matrix.filter((it => it.length > 1)).map((it => it.length - 1)).reduce(((a, b) => a + b), 0);
+                pointer.value.push(...matrix.flat());
             }
         }) ]
     });
     enforceToolCall(agentica);
-    await agentica.conversate([ "Make API operations for below endpoints:", "", "**CRITICAL INSTRUCTIONS**:", "1. Base ALL operation descriptions on ACTUAL fields in the Prisma schema", "2. NEVER reference fields that don't exist (e.g., deleted_at, created_by, updated_by)", "3. For DELETE operations:", "   - Check if the entity has soft delete fields in the schema", "   - If YES: Describe soft delete behavior using those fields", "   - If NO: Describe hard delete behavior (permanent removal)", "4. Every field mentioned in descriptions MUST exist in the Prisma schema", "", "```json", JSON.stringify(Array.from(endpoints), null, 2), "```" ].join("\n")).finally((() => {
+    await agentica.conversate("Make API operations").finally((() => {
         const tokenUsage = agentica.getTokenUsage();
         ctx.usage().record(tokenUsage, [ "interface" ]);
     }));
@@ -2535,13 +2494,13 @@ async function process$4(ctx, endpoints) {
     return pointer.value;
 }
 
-function createApplication$9(props) {
+function createApplication$a(props) {
     assertSchemaModel(props.model);
-    const application = collection$a[props.model];
+    const application = collection$b[props.model];
     application.functions[0].validate = next => {
         const result = (() => {
             const _io0 = input => Array.isArray(input.operations) && input.operations.every((elem => "object" === typeof elem && null !== elem && _io1(elem)));
-            const _io1 = input => "string" === typeof input.specification && "string" === typeof input.description && "string" === typeof input.summary && (Array.isArray(input.parameters) && input.parameters.every((elem => "object" === typeof elem && null !== elem && _io2(elem)))) && (null === input.requestBody || "object" === typeof input.requestBody && null !== input.requestBody && _io6(input.requestBody)) && (null === input.responseBody || "object" === typeof input.responseBody && null !== input.responseBody && _io7(input.responseBody)) && (null === input.authorizationRole || "string" === typeof input.authorizationRole && 1 <= input.authorizationRole.length) && "string" === typeof input.name && "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method);
+            const _io1 = input => Array.isArray(input.authorizationRoles) && input.authorizationRoles.every((elem => "string" === typeof elem && 1 <= elem.length)) && "string" === typeof input.description && "string" === typeof input.name && "string" === typeof input.specification && "string" === typeof input.summary && ("string" === typeof input.path && RegExp("^\\/[a-zA-Z0-9\\/_{}.-]*$").test(input.path)) && (Array.isArray(input.parameters) && input.parameters.every((elem => "object" === typeof elem && null !== elem && _io2(elem)))) && (null === input.requestBody || "object" === typeof input.requestBody && null !== input.requestBody && _io6(input.requestBody)) && (null === input.responseBody || "object" === typeof input.responseBody && null !== input.responseBody && _io7(input.responseBody)) && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method);
             const _io2 = input => "string" === typeof input.name && "string" === typeof input.description && ("object" === typeof input.schema && null !== input.schema && _iu0(input.schema));
             const _io3 = input => (undefined === input.minimum || "number" === typeof input.minimum && (Math.floor(input.minimum) === input.minimum && -0x8000000000000000 <= input.minimum && input.minimum <= 0x8000000000000000)) && (undefined === input.maximum || "number" === typeof input.maximum && (Math.floor(input.maximum) === input.maximum && -0x8000000000000000 <= input.maximum && input.maximum <= 0x8000000000000000)) && (undefined === input.exclusiveMinimum || "number" === typeof input.exclusiveMinimum) && (undefined === input.exclusiveMaximum || "number" === typeof input.exclusiveMaximum) && (undefined === input.multipleOf || "number" === typeof input.multipleOf && (Math.floor(input.multipleOf) === input.multipleOf && 0 <= input.multipleOf && input.multipleOf <= 0x10000000000000000 && 0 < input.multipleOf)) && "integer" === input.type;
             const _io4 = input => (undefined === input.minimum || "number" === typeof input.minimum) && (undefined === input.maximum || "number" === typeof input.maximum) && (undefined === input.exclusiveMinimum || "number" === typeof input.exclusiveMinimum) && (undefined === input.exclusiveMaximum || "number" === typeof input.exclusiveMaximum) && (undefined === input.multipleOf || "number" === typeof input.multipleOf && 0 < input.multipleOf) && "number" === input.type;
@@ -2553,43 +2512,71 @@ function createApplication$9(props) {
             })();
             const _vo0 = (input, _path, _exceptionable = true) => [ (Array.isArray(input.operations) || _report(_exceptionable, {
                 path: _path + ".operations",
-                expected: "Array<AutoBeOpenApi.IOperation>",
+                expected: "Array<IAutoBeInterfaceOperationApplication.IOperation>",
                 value: input.operations
-            })) && input.operations.map(((elem, _index3) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
-                path: _path + ".operations[" + _index3 + "]",
-                expected: "AutoBeOpenApi.IOperation",
+            })) && input.operations.map(((elem, _index4) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                path: _path + ".operations[" + _index4 + "]",
+                expected: "IAutoBeInterfaceOperationApplication.IOperation",
                 value: elem
-            })) && _vo1(elem, _path + ".operations[" + _index3 + "]", _exceptionable) || _report(_exceptionable, {
-                path: _path + ".operations[" + _index3 + "]",
-                expected: "AutoBeOpenApi.IOperation",
+            })) && _vo1(elem, _path + ".operations[" + _index4 + "]", _exceptionable) || _report(_exceptionable, {
+                path: _path + ".operations[" + _index4 + "]",
+                expected: "IAutoBeInterfaceOperationApplication.IOperation",
                 value: elem
             }))).every((flag => flag)) || _report(_exceptionable, {
                 path: _path + ".operations",
-                expected: "Array<AutoBeOpenApi.IOperation>",
+                expected: "Array<IAutoBeInterfaceOperationApplication.IOperation>",
                 value: input.operations
             }) ].every((flag => flag));
-            const _vo1 = (input, _path, _exceptionable = true) => [ "string" === typeof input.specification || _report(_exceptionable, {
-                path: _path + ".specification",
-                expected: "string",
-                value: input.specification
+            const _vo1 = (input, _path, _exceptionable = true) => [ (Array.isArray(input.authorizationRoles) || _report(_exceptionable, {
+                path: _path + ".authorizationRoles",
+                expected: "Array<string & MinLength<1>>",
+                value: input.authorizationRoles
+            })) && input.authorizationRoles.map(((elem, _index5) => "string" === typeof elem && (1 <= elem.length || _report(_exceptionable, {
+                path: _path + ".authorizationRoles[" + _index5 + "]",
+                expected: "string & MinLength<1>",
+                value: elem
+            })) || _report(_exceptionable, {
+                path: _path + ".authorizationRoles[" + _index5 + "]",
+                expected: "(string & MinLength<1>)",
+                value: elem
+            }))).every((flag => flag)) || _report(_exceptionable, {
+                path: _path + ".authorizationRoles",
+                expected: "Array<string & MinLength<1>>",
+                value: input.authorizationRoles
             }), "string" === typeof input.description || _report(_exceptionable, {
                 path: _path + ".description",
                 expected: "string",
                 value: input.description
+            }), "string" === typeof input.name || _report(_exceptionable, {
+                path: _path + ".name",
+                expected: "string",
+                value: input.name
+            }), "string" === typeof input.specification || _report(_exceptionable, {
+                path: _path + ".specification",
+                expected: "string",
+                value: input.specification
             }), "string" === typeof input.summary || _report(_exceptionable, {
                 path: _path + ".summary",
                 expected: "string",
                 value: input.summary
+            }), "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
             }), (Array.isArray(input.parameters) || _report(_exceptionable, {
                 path: _path + ".parameters",
                 expected: "Array<AutoBeOpenApi.IParameter>",
                 value: input.parameters
-            })) && input.parameters.map(((elem, _index4) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
-                path: _path + ".parameters[" + _index4 + "]",
+            })) && input.parameters.map(((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                path: _path + ".parameters[" + _index6 + "]",
                 expected: "AutoBeOpenApi.IParameter",
                 value: elem
-            })) && _vo2(elem, _path + ".parameters[" + _index4 + "]", _exceptionable) || _report(_exceptionable, {
-                path: _path + ".parameters[" + _index4 + "]",
+            })) && _vo2(elem, _path + ".parameters[" + _index6 + "]", _exceptionable) || _report(_exceptionable, {
+                path: _path + ".parameters[" + _index6 + "]",
                 expected: "AutoBeOpenApi.IParameter",
                 value: elem
             }))).every((flag => flag)) || _report(_exceptionable, {
@@ -2612,22 +2599,6 @@ function createApplication$9(props) {
                 path: _path + ".responseBody",
                 expected: "(AutoBeOpenApi.IResponseBody | null)",
                 value: input.responseBody
-            }), null === input.authorizationRole || "string" === typeof input.authorizationRole && (1 <= input.authorizationRole.length || _report(_exceptionable, {
-                path: _path + ".authorizationRole",
-                expected: "string & MinLength<1>",
-                value: input.authorizationRole
-            })) || _report(_exceptionable, {
-                path: _path + ".authorizationRole",
-                expected: "((string & MinLength<1>) | null)",
-                value: input.authorizationRole
-            }), "string" === typeof input.name || _report(_exceptionable, {
-                path: _path + ".name",
-                expected: "string",
-                value: input.name
-            }), "string" === typeof input.path || _report(_exceptionable, {
-                path: _path + ".path",
-                expected: "string",
-                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")',
@@ -2787,11 +2758,11 @@ function createApplication$9(props) {
                     _report = __typia_transform__validateReport._validateReport(errors);
                     ((input, _path, _exceptionable = true) => ("object" === typeof input && null !== input || _report(true, {
                         path: _path + "",
-                        expected: "IMakeOperationProps",
+                        expected: "IAutoBeInterfaceOperationApplication.IProps",
                         value: input
                     })) && _vo0(input, _path + "", true) || _report(true, {
                         path: _path + "",
-                        expected: "IMakeOperationProps",
+                        expected: "IAutoBeInterfaceOperationApplication.IProps",
                         value: input
                     }))(input, "$input", true);
                     const success = 0 === errors.length;
@@ -2819,12 +2790,15 @@ function createApplication$9(props) {
                 expected: "GET method should not have request body. Change method, or re-design the operation.",
                 value: op.requestBody
             });
-            if (props.roles === null) op.authorizationRole = null; else if (op.authorizationRole !== null && !!props.roles?.length && props.roles.find((it => it === op.authorizationRole)) === undefined) errors.push({
-                path: `$input.operations[${i}].authorizationRole`,
-                expected: `null | ${props.roles.map((str => JSON.stringify(str))).join(" | ")}`,
-                description: [ `Role "${op.authorizationRole}" is not defined in the roles list.`, "", "Please select one of them below, or do not define (`null`):  ", "", ...(props.roles ?? []).map((role => `- ${role}`)) ].join("\n"),
-                value: op.authorizationRole
-            });
+            if (props.roles.length === 0) op.authorizationRoles = []; else if (op.authorizationRoles.length !== 0 && props.roles.length !== 0) op.authorizationRoles.forEach(((role, j) => {
+                if (props.roles.includes(role) === true) return;
+                errors.push({
+                    path: `$input.operations[${i}].authorizationRoles[${j}]`,
+                    expected: `null | ${props.roles.map((str => JSON.stringify(str))).join(" | ")}`,
+                    description: [ `Role "${role}" is not defined in the roles list.`, "", "Please select one of them below, or do not define (`null`):  ", "", ...props.roles.map((role => `- ${role}`)) ].join("\n"),
+                    value: role
+                });
+            }));
         }));
         if (errors.length !== 0) return {
             success: false,
@@ -2845,7 +2819,7 @@ function createApplication$9(props) {
     };
 }
 
-const claude$a = {
+const claude$b = {
     model: "claude",
     options: {
         reference: true,
@@ -2854,36 +2828,53 @@ const claude$a = {
     functions: [ {
         name: "makeOperations",
         parameters: {
-            description: " Properties containing the operations to generate.\n\n------------------------------\n\nCurrent Type: {@link IMakeOperationProps}",
+            description: " Properties containing the operations to generate.\n\n------------------------------\n\nCurrent Type: {@link IAutoBeInterfaceOperationApplication.IProps}",
             type: "object",
             properties: {
                 operations: {
-                    description: 'Array of API operations to generate.\n\nEach operation in this array must include:\n\n- Specification: Detailed API specification with clear purpose and\n  functionality\n- Path: Resource-centric URL path (e.g., "/resources/{resourceId}")\n- Method: HTTP method (get, post, put, delete, patch)\n- Description: Extremely detailed multi-paragraph description referencing\n  Prisma schema comments\n- Summary: Concise one-sentence summary of the endpoint\n- Parameters: Array of all necessary parameters with descriptions and schema\n  definitions\n- RequestBody: For POST/PUT/PATCH methods, with typeName referencing\n  components.schemas\n- ResponseBody: With typeName referencing appropriate response type\n\nAll operations must follow strict quality standards:\n\n1. Detailed descriptions referencing Prisma schema comments\n2. Accurate parameter definitions matching path parameters\n3. Appropriate request/response body type references\n4. Consistent patterns for CRUD operations\n\nFor list retrievals (typically PATCH), include pagination, search, and\nsorting. For detail retrieval (GET), return a single resource. For creation\n(POST), use .ICreate request body. For modification (PUT), use .IUpdate\nrequest body.',
+                    description: 'Array of API operations to generate.\n\nEach operation in this array must include:\n\n- Specification: Detailed API specification with clear purpose and\n  functionality\n- Path: Resource-centric URL path (e.g., "/resources/{resourceId}")\n- Method: HTTP method (get, post, put, delete, patch)\n- Description: Extremely detailed multi-paragraph description referencing\n  Prisma schema comments\n- Summary: Concise one-sentence summary of the endpoint\n- Parameters: Array of all necessary parameters with descriptions and\n  schema definitions\n- RequestBody: For POST/PUT/PATCH methods, with typeName referencing\n  components.schemas\n- ResponseBody: With typeName referencing appropriate response type\n\nAll operations must follow strict quality standards:\n\n1. Detailed descriptions referencing Prisma schema comments\n2. Accurate parameter definitions matching path parameters\n3. Appropriate request/response body type references\n4. Consistent patterns for CRUD operations\n\nFor list retrievals (typically PATCH), include pagination, search, and\nsorting. For detail retrieval (GET), return a single resource. For\ncreation (POST), use .ICreate request body. For modification (PUT), use\n.IUpdate request body.',
                     type: "array",
                     items: {
-                        $ref: "#/$defs/AutoBeOpenApi.IOperation"
+                        $ref: "#/$defs/IAutoBeInterfaceOperationApplication.IOperation"
                     }
                 }
             },
             required: [ "operations" ],
             additionalProperties: false,
             $defs: {
-                "AutoBeOpenApi.IOperation": {
+                "IAutoBeInterfaceOperationApplication.IOperation": {
                     description: 'Operation of the Restful API.\n\nThis interface defines a single API endpoint with its HTTP {@link method},\n{@link path}, {@link parameters path parameters},\n{@link requestBody request body}, and {@link responseBody} structure. It\ncorresponds to an individual operation in the paths section of an OpenAPI\ndocument.\n\nEach operation requires a detailed explanation of its purpose through the\nreason and description fields, making it clear why the API was designed and\nhow it should be used.\n\nAll request bodies and responses for this operation must be object types\nand must reference named types defined in the components section. The\ncontent-type is always `application/json`. For file upload/download\noperations, use `string & tags.Format<"uri">` in the appropriate schema\ninstead of binary data formats.\n\nIn OpenAPI, this might represent:\n\n```json\n{\n  "/shoppings/customers/orders": {\n    "post": {\n      "description": "Create a new order application from shopping cart...",\n      "parameters": [...],\n      "requestBody": {...},\n      "responses": {...}\n    }\n  }\n}\n```',
                     type: "object",
                     properties: {
-                        specification: {
-                            description: "Specification of the API operation.\n\nBefore defining the API operation interface, please describe what you're\nplanning to write in this `specification` field.\n\nThe specification must be fully detailed and clear, so that anyone can\nunderstand the purpose and functionality of the API operation and its\nrelated components (e.g., {@link path}, {@link parameters},\n{@link requestBody}).\n\nIMPORTANT: The specification MUST identify which Prisma DB table this\noperation is associated with, helping ensure complete coverage of all\ndatabase entities.",
-                            type: "string"
+                        authorizationRoles: {
+                            description: 'Authorization roles required to access this API operation.\n\nThis field specifies which user roles are allowed to access this\nendpoint. Multiple roles can be specified to allow different types of\nusers to access the same endpoint.\n\n## Important Guidelines\n\n- Set to empty array `[]` for public endpoints that require no\n  authentication\n- Set to array with role strings for role-restricted endpoints\n- The role names MUST match exactly with the user type/role defined in the\n  database\n- This will be used by the Realize Agent to generate appropriate decorator\n  and authorization logic in the provider functions\n- The controller will apply the corresponding authentication decorator\n  based on these roles\n\n## Examples\n\n- `[]` - Public endpoint, no authentication required\n- `["user"]` - Any authenticated user can access\n- `["admin"]` - Only admin users can access\n- `["admin", "moderator"]` - Both admin and moderator users can access\n- `["seller"]` - Only seller users can access\n\nNote: The actual authentication/authorization implementation will be\nhandled by decorators at the controller level, and the provider function\nwill receive the authenticated user object with the appropriate type.',
+                            type: "array",
+                            items: {
+                                type: "string",
+                                minLength: 1
+                            }
                         },
                         description: {
                             description: "Detailed description about the API operation.\n\nIMPORTANT: This field MUST be extensively detailed and MUST reference the\ndescription comments from the related Prisma DB schema tables and\ncolumns. The description should be organized into MULTIPLE PARAGRAPHS\nseparated by line breaks to improve readability and comprehension.\n\nFor example, include separate paragraphs for:\n\n- The purpose and overview of the API operation\n- Security considerations and user permissions\n- Relationship to underlying database entities\n- Validation rules and business logic\n- Related API operations that might be used together with this one\n- Expected behavior and error handling\n\nWhen writing the description, be sure to incorporate the corresponding DB\nschema's description comments, matching the level of detail and style of\nthose comments. This ensures consistency between the API documentation\nand database structure.\n\nIf there's a dependency to other APIs, please describe the dependency API\noperation in this field with detailed reason. For example, if this API\noperation needs a pre-execution of other API operation, it must be\nexplicitly described.\n\n- `GET /shoppings/customers/sales` must be pre-executed to get entire list\n  of summarized sales. Detailed sale information would be obtained by\n  specifying the sale ID in the path parameter.\n\n> MUST be written in English. Never use other languages.",
                             type: "string"
                         },
+                        name: {
+                            description: 'Functional name of the API endpoint.\n\nThis is a semantic identifier that represents the primary function or\npurpose of the API endpoint. It serves as a canonical name that can be\nused for code generation, SDK method names, and internal references.\n\n## Standard Endpoint Names\n\nUse these conventional names based on the endpoint\'s primary function:\n\n- **`index`**: List/search operations that return multiple entities\n\n  - Typically used with PATCH method for complex queries\n  - Example: `PATCH /users` → `name: "index"`\n- **`at`**: Retrieve a specific entity by identifier\n\n  - Typically used with GET method on single resource\n  - Example: `GET /users/{userId}` → `name: "at"`\n- **`create`**: Create a new entity\n\n  - Typically used with POST method\n  - Example: `POST /users` → `name: "create"`\n- **`update`**: Update an existing entity\n\n  - Typically used with PUT method\n  - Example: `PUT /users/{userId}` → `name: "update"`\n- **`erase`**: Delete/remove an entity\n\n  - Typically used with DELETE method\n  - Example: `DELETE /users/{userId}` → `name: "erase"`\n\n## Custom Endpoint Names\n\nFor specialized operations beyond basic CRUD, use descriptive verbs:\n\n- **`activate`**: Enable or turn on a feature/entity\n- **`deactivate`**: Disable or turn off a feature/entity\n- **`approve`**: Approve a request or entity\n- **`reject`**: Reject a request or entity\n- **`publish`**: Make content publicly available\n- **`archive`**: Move to archived state\n- **`restore`**: Restore from archived/deleted state\n- **`duplicate`**: Create a copy of an entity\n- **`transfer`**: Move ownership or change assignment\n- **`validate`**: Validate data or state\n- **`process`**: Execute a business process or workflow\n- **`export`**: Generate downloadable data\n- **`import`**: Process uploaded data\n\n## Naming Guidelines\n\n- Use lowercase, singular verb forms\n- Be concise but descriptive\n- Avoid abbreviations unless widely understood\n- Ensure the name clearly represents the endpoint\'s primary action\n- For nested resources, focus on the action rather than hierarchy\n\nExamples:\n\n- `GET /shopping/orders/{orderId}/items` → `name: "index"` (lists items)\n- `POST /shopping/orders/{orderId}/cancel` → `name: "cancel"`\n- `PUT /users/{userId}/password` → `name: "updatePassword"`',
+                            type: "string"
+                        },
+                        specification: {
+                            description: "Specification of the API operation.\n\nBefore defining the API operation interface, please describe what you're\nplanning to write in this `specification` field.\n\nThe specification must be fully detailed and clear, so that anyone can\nunderstand the purpose and functionality of the API operation and its\nrelated components (e.g., {@link path}, {@link parameters},\n{@link requestBody}).\n\nIMPORTANT: The specification MUST identify which Prisma DB table this\noperation is associated with, helping ensure complete coverage of all\ndatabase entities.",
+                            type: "string"
+                        },
                         summary: {
                             description: "Short summary of the API operation.\n\nThis should be a concise description of the API operation, typically one\nsentence long. It should provide a quick overview of what the API does\nwithout going into too much detail.\n\nThis summary will be used in the OpenAPI documentation to give users a\nquick understanding of the API operation's purpose.\n\nIMPORTANT: The summary should clearly indicate which Prisma DB table this\noperation relates to, helping to ensure all tables have API coverage.\n\n> MUST be written in English. Never use other languages",
                             type: "string"
                         },
+                        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\\/_{}.-]*$"
+                        },
                         parameters: {
                             description: "List of path parameters.\n\nNote that, the {@link AutoBeOpenApi.IParameter.name identifier name} of\npath parameter must be corresponded to the\n{@link path API operation path}.\n\nFor example, if there's an API operation which has {@link path} of\n`/shoppings/customers/sales/{saleId}/questions/${questionId}/comments/${commentId}`,\nits list of {@link AutoBeOpenApi.IParameter.name path parameters} must be\nlike:\n\n- `saleId`\n- `questionId`\n- `commentId`",
                             type: "array",
@@ -2904,25 +2895,8 @@ const claude$a = {
                             oneOf: [ {
                                 type: "null"
                             }, {
-                                $ref: "#/$defs/AutoBeOpenApi.IResponseBody"
-                            } ]
-                        },
-                        authorizationRole: {
-                            description: 'Authorization role required to access this API operation.\n\nThis field specifies which user role is allowed to access this endpoint.\nThe role name must correspond exactly to the actual roles defined in your\nsystem\'s Prisma schema (e.g., "admin", "administrator", "moderator",\n"seller", "buyer", etc.).\n\n## Role-Based Path Convention\n\nWhen authorizationRole is specified, it should align with the path\nstructure:\n\n- If authorizationRole is "admin" → path might be "/admin/resources/{id}"\n- If authorizationRole is "seller" → path might be "/seller/products"\n- Special case: For user\'s own resources, use path prefix "/my/" regardless\n  of role\n\n## Important Guidelines\n\n- Set to `null` for public endpoints that require no authentication\n- Set to specific role string for role-restricted endpoints\n- The role name MUST match exactly with the user type/role defined in the\n  database\n- This role will be used by the Realize Agent to generate appropriate\n  decorator and authorization logic in the provider functions\n- The controller will apply the corresponding authentication decorator\n  based on this role\n\n## Examples\n\n- `null` - Public endpoint, no authentication required\n- `"user"` - Any authenticated user can access\n- `"admin"` - Only admin users can access\n- `"seller"` - Only seller users can access\n- `"moderator"` - Only moderator users can access\n\nNote: The actual authentication/authorization implementation will be\nhandled by decorators at the controller level, and the provider function\nwill receive the authenticated user object with the appropriate type.',
-                            oneOf: [ {
-                                type: "null"
-                            }, {
-                                type: "string",
-                                minLength: 1
-                            } ]
-                        },
-                        name: {
-                            description: 'Functional name of the API endpoint.\n\nThis is a semantic identifier that represents the primary function or\npurpose of the API endpoint. It serves as a canonical name that can be\nused for code generation, SDK method names, and internal references.\n\n## Standard Endpoint Names\n\nUse these conventional names based on the endpoint\'s primary function:\n\n- **`index`**: List/search operations that return multiple entities\n\n  - Typically used with PATCH method for complex queries\n  - Example: `PATCH /users` → `name: "index"`\n- **`at`**: Retrieve a specific entity by identifier\n\n  - Typically used with GET method on single resource\n  - Example: `GET /users/{userId}` → `name: "at"`\n- **`create`**: Create a new entity\n\n  - Typically used with POST method\n  - Example: `POST /users` → `name: "create"`\n- **`update`**: Update an existing entity\n\n  - Typically used with PUT method\n  - Example: `PUT /users/{userId}` → `name: "update"`\n- **`erase`**: Delete/remove an entity\n\n  - Typically used with DELETE method\n  - Example: `DELETE /users/{userId}` → `name: "erase"`\n\n## Custom Endpoint Names\n\nFor specialized operations beyond basic CRUD, use descriptive verbs:\n\n- **`activate`**: Enable or turn on a feature/entity\n- **`deactivate`**: Disable or turn off a feature/entity\n- **`approve`**: Approve a request or entity\n- **`reject`**: Reject a request or entity\n- **`publish`**: Make content publicly available\n- **`archive`**: Move to archived state\n- **`restore`**: Restore from archived/deleted state\n- **`duplicate`**: Create a copy of an entity\n- **`transfer`**: Move ownership or change assignment\n- **`validate`**: Validate data or state\n- **`process`**: Execute a business process or workflow\n- **`export`**: Generate downloadable data\n- **`import`**: Process uploaded data\n\n## Naming Guidelines\n\n- Use lowercase, singular verb forms\n- Be concise but descriptive\n- Avoid abbreviations unless widely understood\n- Ensure the name clearly represents the endpoint\'s primary action\n- For nested resources, focus on the action rather than hierarchy\n\nExamples:\n\n- `GET /shopping/orders/{orderId}/items` → `name: "index"` (lists items)\n- `POST /shopping/orders/{orderId}/cancel` → `name: "cancel"`\n- `PUT /users/{userId}/password` → `name: "updatePassword"`',
-                            type: "string"
-                        },
-                        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.",
-                            type: "string"
+                                $ref: "#/$defs/AutoBeOpenApi.IResponseBody"
+                            } ]
                         },
                         method: {
                             description: "HTTP method of the API operation.\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",
@@ -2939,7 +2913,7 @@ const claude$a = {
                             } ]
                         }
                     },
-                    required: [ "specification", "description", "summary", "parameters", "requestBody", "responseBody", "authorizationRole", "name", "path", "method" ]
+                    required: [ "authorizationRoles", "description", "name", "specification", "summary", "path", "parameters", "requestBody", "responseBody", "method" ]
                 },
                 "AutoBeOpenApi.IParameter": {
                     description: 'Path parameter information for API routes.\n\nThis interface defines a path parameter that appears in the URL of an API\nendpoint. Path parameters are enclosed in curly braces in the\n{@link AutoBeOpenApi.IOperation.path operation path} and must be defined\nwith their types and descriptions.\n\nFor example, if API operation path is\n`/shoppings/customers/sales/{saleId}/questions/${questionId}/comments/${commentId}`,\nthe path parameters should be like below:\n\n```json\n{\n  "path": "/shoppings/customers/sales/{saleId}/questions/${questionId}/comments/${commentId}",\n  "method": "get",\n  "parameters": [\n    {\n      "name": "saleId",\n      "in": "path",\n      "schema": { "type": "string", "format": "uuid" },\n      "description": "Target sale\'s ID"\n    },\n    {\n      "name": "questionId",\n      "in": "path",\n      "schema": { "type": "string", "format": "uuid" },\n      "description": "Target question\'s ID"\n    },\n    {\n      "name": "commentId",\n      "in": "path",\n      "schema": { "type": "string", "format": "uuid" },\n      "description": "Target comment\'s ID"\n    }\n  ]\n}\n```',
@@ -3106,7 +3080,7 @@ const claude$a = {
         description: "Generate detailed API operations from path/method combinations.\n\nThis function creates complete API operations following REST principles and\nquality standards. Each generated operation includes specification, path,\nmethod, detailed multi-paragraph description, concise summary, parameters,\nand appropriate request/response bodies.\n\nThe function processes as many operations as possible in a single call,\nwith progress tracking to ensure iterative completion of all required\nendpoints.",
         validate: (() => {
             const _io0 = input => Array.isArray(input.operations) && input.operations.every((elem => "object" === typeof elem && null !== elem && _io1(elem)));
-            const _io1 = input => "string" === typeof input.specification && "string" === typeof input.description && "string" === typeof input.summary && (Array.isArray(input.parameters) && input.parameters.every((elem => "object" === typeof elem && null !== elem && _io2(elem)))) && (null === input.requestBody || "object" === typeof input.requestBody && null !== input.requestBody && _io6(input.requestBody)) && (null === input.responseBody || "object" === typeof input.responseBody && null !== input.responseBody && _io7(input.responseBody)) && (null === input.authorizationRole || "string" === typeof input.authorizationRole && 1 <= input.authorizationRole.length) && "string" === typeof input.name && "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method);
+            const _io1 = input => Array.isArray(input.authorizationRoles) && input.authorizationRoles.every((elem => "string" === typeof elem && 1 <= elem.length)) && "string" === typeof input.description && "string" === typeof input.name && "string" === typeof input.specification && "string" === typeof input.summary && ("string" === typeof input.path && RegExp("^\\/[a-zA-Z0-9\\/_{}.-]*$").test(input.path)) && (Array.isArray(input.parameters) && input.parameters.every((elem => "object" === typeof elem && null !== elem && _io2(elem)))) && (null === input.requestBody || "object" === typeof input.requestBody && null !== input.requestBody && _io6(input.requestBody)) && (null === input.responseBody || "object" === typeof input.responseBody && null !== input.responseBody && _io7(input.responseBody)) && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method);
             const _io2 = input => "string" === typeof input.name && "string" === typeof input.description && ("object" === typeof input.schema && null !== input.schema && _iu0(input.schema));
             const _io3 = input => (undefined === input.minimum || "number" === typeof input.minimum && (Math.floor(input.minimum) === input.minimum && -0x8000000000000000 <= input.minimum && input.minimum <= 0x8000000000000000)) && (undefined === input.maximum || "number" === typeof input.maximum && (Math.floor(input.maximum) === input.maximum && -0x8000000000000000 <= input.maximum && input.maximum <= 0x8000000000000000)) && (undefined === input.exclusiveMinimum || "number" === typeof input.exclusiveMinimum) && (undefined === input.exclusiveMaximum || "number" === typeof input.exclusiveMaximum) && (undefined === input.multipleOf || "number" === typeof input.multipleOf && (Math.floor(input.multipleOf) === input.multipleOf && 0 <= input.multipleOf && input.multipleOf <= 0x10000000000000000 && 0 < input.multipleOf)) && "integer" === input.type;
             const _io4 = input => (undefined === input.minimum || "number" === typeof input.minimum) && (undefined === input.maximum || "number" === typeof input.maximum) && (undefined === input.exclusiveMinimum || "number" === typeof input.exclusiveMinimum) && (undefined === input.exclusiveMaximum || "number" === typeof input.exclusiveMaximum) && (undefined === input.multipleOf || "number" === typeof input.multipleOf && 0 < input.multipleOf) && "number" === input.type;
@@ -3118,43 +3092,71 @@ const claude$a = {
             })();
             const _vo0 = (input, _path, _exceptionable = true) => [ (Array.isArray(input.operations) || _report(_exceptionable, {
                 path: _path + ".operations",
-                expected: "Array<AutoBeOpenApi.IOperation>",
+                expected: "Array<IAutoBeInterfaceOperationApplication.IOperation>",
                 value: input.operations
-            })) && input.operations.map(((elem, _index3) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
-                path: _path + ".operations[" + _index3 + "]",
-                expected: "AutoBeOpenApi.IOperation",
+            })) && input.operations.map(((elem, _index4) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                path: _path + ".operations[" + _index4 + "]",
+                expected: "IAutoBeInterfaceOperationApplication.IOperation",
                 value: elem
-            })) && _vo1(elem, _path + ".operations[" + _index3 + "]", _exceptionable) || _report(_exceptionable, {
-                path: _path + ".operations[" + _index3 + "]",
-                expected: "AutoBeOpenApi.IOperation",
+            })) && _vo1(elem, _path + ".operations[" + _index4 + "]", _exceptionable) || _report(_exceptionable, {
+                path: _path + ".operations[" + _index4 + "]",
+                expected: "IAutoBeInterfaceOperationApplication.IOperation",
                 value: elem
             }))).every((flag => flag)) || _report(_exceptionable, {
                 path: _path + ".operations",
-                expected: "Array<AutoBeOpenApi.IOperation>",
+                expected: "Array<IAutoBeInterfaceOperationApplication.IOperation>",
                 value: input.operations
             }) ].every((flag => flag));
-            const _vo1 = (input, _path, _exceptionable = true) => [ "string" === typeof input.specification || _report(_exceptionable, {
-                path: _path + ".specification",
-                expected: "string",
-                value: input.specification
+            const _vo1 = (input, _path, _exceptionable = true) => [ (Array.isArray(input.authorizationRoles) || _report(_exceptionable, {
+                path: _path + ".authorizationRoles",
+                expected: "Array<string & MinLength<1>>",
+                value: input.authorizationRoles
+            })) && input.authorizationRoles.map(((elem, _index5) => "string" === typeof elem && (1 <= elem.length || _report(_exceptionable, {
+                path: _path + ".authorizationRoles[" + _index5 + "]",
+                expected: "string & MinLength<1>",
+                value: elem
+            })) || _report(_exceptionable, {
+                path: _path + ".authorizationRoles[" + _index5 + "]",
+                expected: "(string & MinLength<1>)",
+                value: elem
+            }))).every((flag => flag)) || _report(_exceptionable, {
+                path: _path + ".authorizationRoles",
+                expected: "Array<string & MinLength<1>>",
+                value: input.authorizationRoles
             }), "string" === typeof input.description || _report(_exceptionable, {
                 path: _path + ".description",
                 expected: "string",
                 value: input.description
+            }), "string" === typeof input.name || _report(_exceptionable, {
+                path: _path + ".name",
+                expected: "string",
+                value: input.name
+            }), "string" === typeof input.specification || _report(_exceptionable, {
+                path: _path + ".specification",
+                expected: "string",
+                value: input.specification
             }), "string" === typeof input.summary || _report(_exceptionable, {
                 path: _path + ".summary",
                 expected: "string",
                 value: input.summary
+            }), "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
             }), (Array.isArray(input.parameters) || _report(_exceptionable, {
                 path: _path + ".parameters",
                 expected: "Array<AutoBeOpenApi.IParameter>",
                 value: input.parameters
-            })) && input.parameters.map(((elem, _index4) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
-                path: _path + ".parameters[" + _index4 + "]",
+            })) && input.parameters.map(((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                path: _path + ".parameters[" + _index6 + "]",
                 expected: "AutoBeOpenApi.IParameter",
                 value: elem
-            })) && _vo2(elem, _path + ".parameters[" + _index4 + "]", _exceptionable) || _report(_exceptionable, {
-                path: _path + ".parameters[" + _index4 + "]",
+            })) && _vo2(elem, _path + ".parameters[" + _index6 + "]", _exceptionable) || _report(_exceptionable, {
+                path: _path + ".parameters[" + _index6 + "]",
                 expected: "AutoBeOpenApi.IParameter",
                 value: elem
             }))).every((flag => flag)) || _report(_exceptionable, {
@@ -3177,22 +3179,6 @@ const claude$a = {
                 path: _path + ".responseBody",
                 expected: "(AutoBeOpenApi.IResponseBody | null)",
                 value: input.responseBody
-            }), null === input.authorizationRole || "string" === typeof input.authorizationRole && (1 <= input.authorizationRole.length || _report(_exceptionable, {
-                path: _path + ".authorizationRole",
-                expected: "string & MinLength<1>",
-                value: input.authorizationRole
-            })) || _report(_exceptionable, {
-                path: _path + ".authorizationRole",
-                expected: "((string & MinLength<1>) | null)",
-                value: input.authorizationRole
-            }), "string" === typeof input.name || _report(_exceptionable, {
-                path: _path + ".name",
-                expected: "string",
-                value: input.name
-            }), "string" === typeof input.path || _report(_exceptionable, {
-                path: _path + ".path",
-                expected: "string",
-                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")',
@@ -3352,11 +3338,11 @@ const claude$a = {
                     _report = __typia_transform__validateReport._validateReport(errors);
                     ((input, _path, _exceptionable = true) => ("object" === typeof input && null !== input || _report(true, {
                         path: _path + "",
-                        expected: "IMakeOperationProps",
+                        expected: "IAutoBeInterfaceOperationApplication.IProps",
                         value: input
                     })) && _vo0(input, _path + "", true) || _report(true, {
                         path: _path + "",
-                        expected: "IMakeOperationProps",
+                        expected: "IAutoBeInterfaceOperationApplication.IProps",
                         value: input
                     }))(input, "$input", true);
                     const success = 0 === errors.length;
@@ -3378,7 +3364,7 @@ const claude$a = {
     } ]
 };
 
-const collection$a = {
+const collection$b = {
     chatgpt: {
         model: "chatgpt",
         options: {
@@ -3389,36 +3375,52 @@ const collection$a = {
         functions: [ {
             name: "makeOperations",
             parameters: {
-                description: " Properties containing the operations to generate.\n\n------------------------------\n\nCurrent Type: {@link IMakeOperationProps}",
+                description: " Properties containing the operations to generate.\n\n------------------------------\n\nCurrent Type: {@link IAutoBeInterfaceOperationApplication.IProps}",
                 type: "object",
                 properties: {
                     operations: {
-                        description: 'Array of API operations to generate.\n\nEach operation in this array must include:\n\n- Specification: Detailed API specification with clear purpose and\n  functionality\n- Path: Resource-centric URL path (e.g., "/resources/{resourceId}")\n- Method: HTTP method (get, post, put, delete, patch)\n- Description: Extremely detailed multi-paragraph description referencing\n  Prisma schema comments\n- Summary: Concise one-sentence summary of the endpoint\n- Parameters: Array of all necessary parameters with descriptions and schema\n  definitions\n- RequestBody: For POST/PUT/PATCH methods, with typeName referencing\n  components.schemas\n- ResponseBody: With typeName referencing appropriate response type\n\nAll operations must follow strict quality standards:\n\n1. Detailed descriptions referencing Prisma schema comments\n2. Accurate parameter definitions matching path parameters\n3. Appropriate request/response body type references\n4. Consistent patterns for CRUD operations\n\nFor list retrievals (typically PATCH), include pagination, search, and\nsorting. For detail retrieval (GET), return a single resource. For creation\n(POST), use .ICreate request body. For modification (PUT), use .IUpdate\nrequest body.',
+                        description: 'Array of API operations to generate.\n\nEach operation in this array must include:\n\n- Specification: Detailed API specification with clear purpose and\n  functionality\n- Path: Resource-centric URL path (e.g., "/resources/{resourceId}")\n- Method: HTTP method (get, post, put, delete, patch)\n- Description: Extremely detailed multi-paragraph description referencing\n  Prisma schema comments\n- Summary: Concise one-sentence summary of the endpoint\n- Parameters: Array of all necessary parameters with descriptions and\n  schema definitions\n- RequestBody: For POST/PUT/PATCH methods, with typeName referencing\n  components.schemas\n- ResponseBody: With typeName referencing appropriate response type\n\nAll operations must follow strict quality standards:\n\n1. Detailed descriptions referencing Prisma schema comments\n2. Accurate parameter definitions matching path parameters\n3. Appropriate request/response body type references\n4. Consistent patterns for CRUD operations\n\nFor list retrievals (typically PATCH), include pagination, search, and\nsorting. For detail retrieval (GET), return a single resource. For\ncreation (POST), use .ICreate request body. For modification (PUT), use\n.IUpdate request body.',
                         type: "array",
                         items: {
-                            $ref: "#/$defs/AutoBeOpenApi.IOperation"
+                            $ref: "#/$defs/IAutoBeInterfaceOperationApplication.IOperation"
                         }
                     }
                 },
                 required: [ "operations" ],
                 additionalProperties: false,
                 $defs: {
-                    "AutoBeOpenApi.IOperation": {
+                    "IAutoBeInterfaceOperationApplication.IOperation": {
                         description: 'Operation of the Restful API.\n\nThis interface defines a single API endpoint with its HTTP {@link method},\n{@link path}, {@link parameters path parameters},\n{@link requestBody request body}, and {@link responseBody} structure. It\ncorresponds to an individual operation in the paths section of an OpenAPI\ndocument.\n\nEach operation requires a detailed explanation of its purpose through the\nreason and description fields, making it clear why the API was designed and\nhow it should be used.\n\nAll request bodies and responses for this operation must be object types\nand must reference named types defined in the components section. The\ncontent-type is always `application/json`. For file upload/download\noperations, use `string & tags.Format<"uri">` in the appropriate schema\ninstead of binary data formats.\n\nIn OpenAPI, this might represent:\n\n```json\n{\n  "/shoppings/customers/orders": {\n    "post": {\n      "description": "Create a new order application from shopping cart...",\n      "parameters": [...],\n      "requestBody": {...},\n      "responses": {...}\n    }\n  }\n}\n```',
                         type: "object",
                         properties: {
-                            specification: {
-                                description: "Specification of the API operation.\n\nBefore defining the API operation interface, please describe what you're\nplanning to write in this `specification` field.\n\nThe specification must be fully detailed and clear, so that anyone can\nunderstand the purpose and functionality of the API operation and its\nrelated components (e.g., {@link path}, {@link parameters},\n{@link requestBody}).\n\nIMPORTANT: The specification MUST identify which Prisma DB table this\noperation is associated with, helping ensure complete coverage of all\ndatabase entities.",
-                                type: "string"
+                            authorizationRoles: {
+                                description: 'Authorization roles required to access this API operation.\n\nThis field specifies which user roles are allowed to access this\nendpoint. Multiple roles can be specified to allow different types of\nusers to access the same endpoint.\n\n## Important Guidelines\n\n- Set to empty array `[]` for public endpoints that require no\n  authentication\n- Set to array with role strings for role-restricted endpoints\n- The role names MUST match exactly with the user type/role defined in the\n  database\n- This will be used by the Realize Agent to generate appropriate decorator\n  and authorization logic in the provider functions\n- The controller will apply the corresponding authentication decorator\n  based on these roles\n\n## Examples\n\n- `[]` - Public endpoint, no authentication required\n- `["user"]` - Any authenticated user can access\n- `["admin"]` - Only admin users can access\n- `["admin", "moderator"]` - Both admin and moderator users can access\n- `["seller"]` - Only seller users can access\n\nNote: The actual authentication/authorization implementation will be\nhandled by decorators at the controller level, and the provider function\nwill receive the authenticated user object with the appropriate type.',
+                                type: "array",
+                                items: {
+                                    description: "@minLength 1",
+                                    type: "string"
+                                }
                             },
                             description: {
                                 description: "Detailed description about the API operation.\n\nIMPORTANT: This field MUST be extensively detailed and MUST reference the\ndescription comments from the related Prisma DB schema tables and\ncolumns. The description should be organized into MULTIPLE PARAGRAPHS\nseparated by line breaks to improve readability and comprehension.\n\nFor example, include separate paragraphs for:\n\n- The purpose and overview of the API operation\n- Security considerations and user permissions\n- Relationship to underlying database entities\n- Validation rules and business logic\n- Related API operations that might be used together with this one\n- Expected behavior and error handling\n\nWhen writing the description, be sure to incorporate the corresponding DB\nschema's description comments, matching the level of detail and style of\nthose comments. This ensures consistency between the API documentation\nand database structure.\n\nIf there's a dependency to other APIs, please describe the dependency API\noperation in this field with detailed reason. For example, if this API\noperation needs a pre-execution of other API operation, it must be\nexplicitly described.\n\n- `GET /shoppings/customers/sales` must be pre-executed to get entire list\n  of summarized sales. Detailed sale information would be obtained by\n  specifying the sale ID in the path parameter.\n\n> MUST be written in English. Never use other languages.",
                                 type: "string"
                             },
+                            name: {
+                                description: 'Functional name of the API endpoint.\n\nThis is a semantic identifier that represents the primary function or\npurpose of the API endpoint. It serves as a canonical name that can be\nused for code generation, SDK method names, and internal references.\n\n## Standard Endpoint Names\n\nUse these conventional names based on the endpoint\'s primary function:\n\n- **`index`**: List/search operations that return multiple entities\n\n  - Typically used with PATCH method for complex queries\n  - Example: `PATCH /users` → `name: "index"`\n- **`at`**: Retrieve a specific entity by identifier\n\n  - Typically used with GET method on single resource\n  - Example: `GET /users/{userId}` → `name: "at"`\n- **`create`**: Create a new entity\n\n  - Typically used with POST method\n  - Example: `POST /users` → `name: "create"`\n- **`update`**: Update an existing entity\n\n  - Typically used with PUT method\n  - Example: `PUT /users/{userId}` → `name: "update"`\n- **`erase`**: Delete/remove an entity\n\n  - Typically used with DELETE method\n  - Example: `DELETE /users/{userId}` → `name: "erase"`\n\n## Custom Endpoint Names\n\nFor specialized operations beyond basic CRUD, use descriptive verbs:\n\n- **`activate`**: Enable or turn on a feature/entity\n- **`deactivate`**: Disable or turn off a feature/entity\n- **`approve`**: Approve a request or entity\n- **`reject`**: Reject a request or entity\n- **`publish`**: Make content publicly available\n- **`archive`**: Move to archived state\n- **`restore`**: Restore from archived/deleted state\n- **`duplicate`**: Create a copy of an entity\n- **`transfer`**: Move ownership or change assignment\n- **`validate`**: Validate data or state\n- **`process`**: Execute a business process or workflow\n- **`export`**: Generate downloadable data\n- **`import`**: Process uploaded data\n\n## Naming Guidelines\n\n- Use lowercase, singular verb forms\n- Be concise but descriptive\n- Avoid abbreviations unless widely understood\n- Ensure the name clearly represents the endpoint\'s primary action\n- For nested resources, focus on the action rather than hierarchy\n\nExamples:\n\n- `GET /shopping/orders/{orderId}/items` → `name: "index"` (lists items)\n- `POST /shopping/orders/{orderId}/cancel` → `name: "cancel"`\n- `PUT /users/{userId}/password` → `name: "updatePassword"`',
+                                type: "string"
+                            },
+                            specification: {
+                                description: "Specification of the API operation.\n\nBefore defining the API operation interface, please describe what you're\nplanning to write in this `specification` field.\n\nThe specification must be fully detailed and clear, so that anyone can\nunderstand the purpose and functionality of the API operation and its\nrelated components (e.g., {@link path}, {@link parameters},\n{@link requestBody}).\n\nIMPORTANT: The specification MUST identify which Prisma DB table this\noperation is associated with, helping ensure complete coverage of all\ndatabase entities.",
+                                type: "string"
+                            },
                             summary: {
                                 description: "Short summary of the API operation.\n\nThis should be a concise description of the API operation, typically one\nsentence long. It should provide a quick overview of what the API does\nwithout going into too much detail.\n\nThis summary will be used in the OpenAPI documentation to give users a\nquick understanding of the API operation's purpose.\n\nIMPORTANT: The summary should clearly indicate which Prisma DB table this\noperation relates to, helping to ensure all tables have API coverage.\n\n> MUST be written in English. Never use other languages",
                                 type: "string"
                             },
+                            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"
+                            },
                             parameters: {
                                 description: "List of path parameters.\n\nNote that, the {@link AutoBeOpenApi.IParameter.name identifier name} of\npath parameter must be corresponded to the\n{@link path API operation path}.\n\nFor example, if there's an API operation which has {@link path} of\n`/shoppings/customers/sales/{saleId}/questions/${questionId}/comments/${commentId}`,\nits list of {@link AutoBeOpenApi.IParameter.name path parameters} must be\nlike:\n\n- `saleId`\n- `questionId`\n- `commentId`",
                                 type: "array",
@@ -3442,30 +3444,13 @@ const collection$a = {
                                     $ref: "#/$defs/AutoBeOpenApi.IResponseBody"
                                 } ]
                             },
-                            authorizationRole: {
-                                description: 'Authorization role required to access this API operation.\n\nThis field specifies which user role is allowed to access this endpoint.\nThe role name must correspond exactly to the actual roles defined in your\nsystem\'s Prisma schema (e.g., "admin", "administrator", "moderator",\n"seller", "buyer", etc.).\n\n## Role-Based Path Convention\n\nWhen authorizationRole is specified, it should align with the path\nstructure:\n\n- If authorizationRole is "admin" → path might be "/admin/resources/{id}"\n- If authorizationRole is "seller" → path might be "/seller/products"\n- Special case: For user\'s own resources, use path prefix "/my/" regardless\n  of role\n\n## Important Guidelines\n\n- Set to `null` for public endpoints that require no authentication\n- Set to specific role string for role-restricted endpoints\n- The role name MUST match exactly with the user type/role defined in the\n  database\n- This role will be used by the Realize Agent to generate appropriate\n  decorator and authorization logic in the provider functions\n- The controller will apply the corresponding authentication decorator\n  based on this role\n\n## Examples\n\n- `null` - Public endpoint, no authentication required\n- `"user"` - Any authenticated user can access\n- `"admin"` - Only admin users can access\n- `"seller"` - Only seller users can access\n- `"moderator"` - Only moderator users can access\n\nNote: The actual authentication/authorization implementation will be\nhandled by decorators at the controller level, and the provider function\nwill receive the authenticated user object with the appropriate type.',
-                                anyOf: [ {
-                                    type: "null"
-                                }, {
-                                    type: "string",
-                                    description: "@minLength 1"
-                                } ]
-                            },
-                            name: {
-                                description: 'Functional name of the API endpoint.\n\nThis is a semantic identifier that represents the primary function or\npurpose of the API endpoint. It serves as a canonical name that can be\nused for code generation, SDK method names, and internal references.\n\n## Standard Endpoint Names\n\nUse these conventional names based on the endpoint\'s primary function:\n\n- **`index`**: List/search operations that return multiple entities\n\n  - Typically used with PATCH method for complex queries\n  - Example: `PATCH /users` → `name: "index"`\n- **`at`**: Retrieve a specific entity by identifier\n\n  - Typically used with GET method on single resource\n  - Example: `GET /users/{userId}` → `name: "at"`\n- **`create`**: Create a new entity\n\n  - Typically used with POST method\n  - Example: `POST /users` → `name: "create"`\n- **`update`**: Update an existing entity\n\n  - Typically used with PUT method\n  - Example: `PUT /users/{userId}` → `name: "update"`\n- **`erase`**: Delete/remove an entity\n\n  - Typically used with DELETE method\n  - Example: `DELETE /users/{userId}` → `name: "erase"`\n\n## Custom Endpoint Names\n\nFor specialized operations beyond basic CRUD, use descriptive verbs:\n\n- **`activate`**: Enable or turn on a feature/entity\n- **`deactivate`**: Disable or turn off a feature/entity\n- **`approve`**: Approve a request or entity\n- **`reject`**: Reject a request or entity\n- **`publish`**: Make content publicly available\n- **`archive`**: Move to archived state\n- **`restore`**: Restore from archived/deleted state\n- **`duplicate`**: Create a copy of an entity\n- **`transfer`**: Move ownership or change assignment\n- **`validate`**: Validate data or state\n- **`process`**: Execute a business process or workflow\n- **`export`**: Generate downloadable data\n- **`import`**: Process uploaded data\n\n## Naming Guidelines\n\n- Use lowercase, singular verb forms\n- Be concise but descriptive\n- Avoid abbreviations unless widely understood\n- Ensure the name clearly represents the endpoint\'s primary action\n- For nested resources, focus on the action rather than hierarchy\n\nExamples:\n\n- `GET /shopping/orders/{orderId}/items` → `name: "index"` (lists items)\n- `POST /shopping/orders/{orderId}/cancel` → `name: "cancel"`\n- `PUT /users/{userId}/password` → `name: "updatePassword"`',
-                                type: "string"
-                            },
-                            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.",
-                                type: "string"
-                            },
                             method: {
                                 description: "HTTP method of the API operation.\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: [ "specification", "description", "summary", "parameters", "requestBody", "responseBody", "authorizationRole", "name", "path", "method" ]
+                        required: [ "authorizationRoles", "description", "name", "specification", "summary", "path", "parameters", "requestBody", "responseBody", "method" ]
                     },
                     "AutoBeOpenApi.IParameter": {
                         description: 'Path parameter information for API routes.\n\nThis interface defines a path parameter that appears in the URL of an API\nendpoint. Path parameters are enclosed in curly braces in the\n{@link AutoBeOpenApi.IOperation.path operation path} and must be defined\nwith their types and descriptions.\n\nFor example, if API operation path is\n`/shoppings/customers/sales/{saleId}/questions/${questionId}/comments/${commentId}`,\nthe path parameters should be like below:\n\n```json\n{\n  "path": "/shoppings/customers/sales/{saleId}/questions/${questionId}/comments/${commentId}",\n  "method": "get",\n  "parameters": [\n    {\n      "name": "saleId",\n      "in": "path",\n      "schema": { "type": "string", "format": "uuid" },\n      "description": "Target sale\'s ID"\n    },\n    {\n      "name": "questionId",\n      "in": "path",\n      "schema": { "type": "string", "format": "uuid" },\n      "description": "Target question\'s ID"\n    },\n    {\n      "name": "commentId",\n      "in": "path",\n      "schema": { "type": "string", "format": "uuid" },\n      "description": "Target comment\'s ID"\n    }\n  ]\n}\n```',
@@ -3631,7 +3616,7 @@ const collection$a = {
             description: "Generate detailed API operations from path/method combinations.\n\nThis function creates complete API operations following REST principles and\nquality standards. Each generated operation includes specification, path,\nmethod, detailed multi-paragraph description, concise summary, parameters,\nand appropriate request/response bodies.\n\nThe function processes as many operations as possible in a single call,\nwith progress tracking to ensure iterative completion of all required\nendpoints.",
             validate: (() => {
                 const _io0 = input => Array.isArray(input.operations) && input.operations.every((elem => "object" === typeof elem && null !== elem && _io1(elem)));
-                const _io1 = input => "string" === typeof input.specification && "string" === typeof input.description && "string" === typeof input.summary && (Array.isArray(input.parameters) && input.parameters.every((elem => "object" === typeof elem && null !== elem && _io2(elem)))) && (null === input.requestBody || "object" === typeof input.requestBody && null !== input.requestBody && _io6(input.requestBody)) && (null === input.responseBody || "object" === typeof input.responseBody && null !== input.responseBody && _io7(input.responseBody)) && (null === input.authorizationRole || "string" === typeof input.authorizationRole && 1 <= input.authorizationRole.length) && "string" === typeof input.name && "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method);
+                const _io1 = input => Array.isArray(input.authorizationRoles) && input.authorizationRoles.every((elem => "string" === typeof elem && 1 <= elem.length)) && "string" === typeof input.description && "string" === typeof input.name && "string" === typeof input.specification && "string" === typeof input.summary && ("string" === typeof input.path && RegExp("^\\/[a-zA-Z0-9\\/_{}.-]*$").test(input.path)) && (Array.isArray(input.parameters) && input.parameters.every((elem => "object" === typeof elem && null !== elem && _io2(elem)))) && (null === input.requestBody || "object" === typeof input.requestBody && null !== input.requestBody && _io6(input.requestBody)) && (null === input.responseBody || "object" === typeof input.responseBody && null !== input.responseBody && _io7(input.responseBody)) && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method);
                 const _io2 = input => "string" === typeof input.name && "string" === typeof input.description && ("object" === typeof input.schema && null !== input.schema && _iu0(input.schema));
                 const _io3 = input => (undefined === input.minimum || "number" === typeof input.minimum && (Math.floor(input.minimum) === input.minimum && -0x8000000000000000 <= input.minimum && input.minimum <= 0x8000000000000000)) && (undefined === input.maximum || "number" === typeof input.maximum && (Math.floor(input.maximum) === input.maximum && -0x8000000000000000 <= input.maximum && input.maximum <= 0x8000000000000000)) && (undefined === input.exclusiveMinimum || "number" === typeof input.exclusiveMinimum) && (undefined === input.exclusiveMaximum || "number" === typeof input.exclusiveMaximum) && (undefined === input.multipleOf || "number" === typeof input.multipleOf && (Math.floor(input.multipleOf) === input.multipleOf && 0 <= input.multipleOf && input.multipleOf <= 0x10000000000000000 && 0 < input.multipleOf)) && "integer" === input.type;
                 const _io4 = input => (undefined === input.minimum || "number" === typeof input.minimum) && (undefined === input.maximum || "number" === typeof input.maximum) && (undefined === input.exclusiveMinimum || "number" === typeof input.exclusiveMinimum) && (undefined === input.exclusiveMaximum || "number" === typeof input.exclusiveMaximum) && (undefined === input.multipleOf || "number" === typeof input.multipleOf && 0 < input.multipleOf) && "number" === input.type;
@@ -3643,43 +3628,71 @@ const collection$a = {
                 })();
                 const _vo0 = (input, _path, _exceptionable = true) => [ (Array.isArray(input.operations) || _report(_exceptionable, {
                     path: _path + ".operations",
-                    expected: "Array<AutoBeOpenApi.IOperation>",
+                    expected: "Array<IAutoBeInterfaceOperationApplication.IOperation>",
                     value: input.operations
-                })) && input.operations.map(((elem, _index3) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
-                    path: _path + ".operations[" + _index3 + "]",
-                    expected: "AutoBeOpenApi.IOperation",
+                })) && input.operations.map(((elem, _index4) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                    path: _path + ".operations[" + _index4 + "]",
+                    expected: "IAutoBeInterfaceOperationApplication.IOperation",
                     value: elem
-                })) && _vo1(elem, _path + ".operations[" + _index3 + "]", _exceptionable) || _report(_exceptionable, {
-                    path: _path + ".operations[" + _index3 + "]",
-                    expected: "AutoBeOpenApi.IOperation",
+                })) && _vo1(elem, _path + ".operations[" + _index4 + "]", _exceptionable) || _report(_exceptionable, {
+                    path: _path + ".operations[" + _index4 + "]",
+                    expected: "IAutoBeInterfaceOperationApplication.IOperation",
                     value: elem
                 }))).every((flag => flag)) || _report(_exceptionable, {
                     path: _path + ".operations",
-                    expected: "Array<AutoBeOpenApi.IOperation>",
+                    expected: "Array<IAutoBeInterfaceOperationApplication.IOperation>",
                     value: input.operations
                 }) ].every((flag => flag));
-                const _vo1 = (input, _path, _exceptionable = true) => [ "string" === typeof input.specification || _report(_exceptionable, {
-                    path: _path + ".specification",
-                    expected: "string",
-                    value: input.specification
+                const _vo1 = (input, _path, _exceptionable = true) => [ (Array.isArray(input.authorizationRoles) || _report(_exceptionable, {
+                    path: _path + ".authorizationRoles",
+                    expected: "Array<string & MinLength<1>>",
+                    value: input.authorizationRoles
+                })) && input.authorizationRoles.map(((elem, _index5) => "string" === typeof elem && (1 <= elem.length || _report(_exceptionable, {
+                    path: _path + ".authorizationRoles[" + _index5 + "]",
+                    expected: "string & MinLength<1>",
+                    value: elem
+                })) || _report(_exceptionable, {
+                    path: _path + ".authorizationRoles[" + _index5 + "]",
+                    expected: "(string & MinLength<1>)",
+                    value: elem
+                }))).every((flag => flag)) || _report(_exceptionable, {
+                    path: _path + ".authorizationRoles",
+                    expected: "Array<string & MinLength<1>>",
+                    value: input.authorizationRoles
                 }), "string" === typeof input.description || _report(_exceptionable, {
                     path: _path + ".description",
                     expected: "string",
                     value: input.description
+                }), "string" === typeof input.name || _report(_exceptionable, {
+                    path: _path + ".name",
+                    expected: "string",
+                    value: input.name
+                }), "string" === typeof input.specification || _report(_exceptionable, {
+                    path: _path + ".specification",
+                    expected: "string",
+                    value: input.specification
                 }), "string" === typeof input.summary || _report(_exceptionable, {
                     path: _path + ".summary",
                     expected: "string",
                     value: input.summary
+                }), "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
                 }), (Array.isArray(input.parameters) || _report(_exceptionable, {
                     path: _path + ".parameters",
                     expected: "Array<AutoBeOpenApi.IParameter>",
                     value: input.parameters
-                })) && input.parameters.map(((elem, _index4) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
-                    path: _path + ".parameters[" + _index4 + "]",
+                })) && input.parameters.map(((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                    path: _path + ".parameters[" + _index6 + "]",
                     expected: "AutoBeOpenApi.IParameter",
                     value: elem
-                })) && _vo2(elem, _path + ".parameters[" + _index4 + "]", _exceptionable) || _report(_exceptionable, {
-                    path: _path + ".parameters[" + _index4 + "]",
+                })) && _vo2(elem, _path + ".parameters[" + _index6 + "]", _exceptionable) || _report(_exceptionable, {
+                    path: _path + ".parameters[" + _index6 + "]",
                     expected: "AutoBeOpenApi.IParameter",
                     value: elem
                 }))).every((flag => flag)) || _report(_exceptionable, {
@@ -3702,22 +3715,6 @@ const collection$a = {
                     path: _path + ".responseBody",
                     expected: "(AutoBeOpenApi.IResponseBody | null)",
                     value: input.responseBody
-                }), null === input.authorizationRole || "string" === typeof input.authorizationRole && (1 <= input.authorizationRole.length || _report(_exceptionable, {
-                    path: _path + ".authorizationRole",
-                    expected: "string & MinLength<1>",
-                    value: input.authorizationRole
-                })) || _report(_exceptionable, {
-                    path: _path + ".authorizationRole",
-                    expected: "((string & MinLength<1>) | null)",
-                    value: input.authorizationRole
-                }), "string" === typeof input.name || _report(_exceptionable, {
-                    path: _path + ".name",
-                    expected: "string",
-                    value: input.name
-                }), "string" === typeof input.path || _report(_exceptionable, {
-                    path: _path + ".path",
-                    expected: "string",
-                    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")',
@@ -3852,22 +3849,365 @@ const collection$a = {
                     expected: "string",
                     value: input.typeName
                 }) ].every((flag => flag));
-                const _vo7 = (input, _path, _exceptionable = true) => [ "string" === typeof input.description || _report(_exceptionable, {
+                const _vo7 = (input, _path, _exceptionable = true) => [ "string" === typeof input.description || _report(_exceptionable, {
+                    path: _path + ".description",
+                    expected: "string",
+                    value: input.description
+                }), "string" === typeof input.typeName || _report(_exceptionable, {
+                    path: _path + ".typeName",
+                    expected: "string",
+                    value: input.typeName
+                }) ].every((flag => flag));
+                const _vu0 = (input, _path, _exceptionable = true) => (() => {
+                    if ("number" === input.type) return _vo4(input, _path, _exceptionable); else if ("integer" === input.type) return _vo3(input, _path, _exceptionable); else if ("string" === input.type) return _vo5(input, _path, _exceptionable); else return _report(_exceptionable, {
+                        path: _path,
+                        expected: "(AutoBeOpenApi.IJsonSchema.INumber | AutoBeOpenApi.IJsonSchema.IInteger | AutoBeOpenApi.IJsonSchema.IString)",
+                        value: input
+                    });
+                })();
+                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: "IAutoBeInterfaceOperationApplication.IProps",
+                            value: input
+                        })) && _vo0(input, _path + "", true) || _report(true, {
+                            path: _path + "",
+                            expected: "IAutoBeInterfaceOperationApplication.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
+                    };
+                };
+            })()
+        } ]
+    },
+    claude: claude$b,
+    llama: claude$b,
+    deepseek: claude$b,
+    3.1: claude$b
+};
+
+const transformInterfaceSchemaHistories = (state, operations) => [ {
+    type: "systemMessage",
+    id: v4(),
+    created_at: (new Date).toISOString(),
+    text: '# AutoAPI Schema Agent System Prompt\n\nYou are AutoAPI Schema Agent, an expert in creating comprehensive schema definitions for OpenAPI specifications in the `AutoBeOpenApi.IJsonSchemaDescriptive` format. Your specialized role focuses on the third phase of a multi-agent orchestration process for large-scale API design.\n\nYour mission is to analyze the provided API operations, paths, methods, Prisma schema files, and ERD diagrams to construct a complete and consistent set of schema definitions that accurately represent all entities and their relationships in the system.\n\n## 1. Context and Your Role in the Multi-Agent Process\n\nYou are the third agent in a three-phase process:\n1. **Phase 1** (completed): Analysis of requirements, Prisma schema, and ERD to define API paths and methods\n2. **Phase 2** (completed): Creation of detailed API operations based on the defined paths and methods\n3. **Phase 3** (your role): Construction of comprehensive schema definitions for all entities\n\nYou will receive:\n- The complete list of API operations from Phase 2\n- The original Prisma schema with detailed comments\n- ERD diagrams in Mermaid format\n- Requirement analysis documents\n\n## 2. Primary Responsibilities\n\nYour specific tasks are:\n\n1. **Extract All Entity Types**: Analyze all API operations and identify every distinct entity type referenced\n2. **Define Complete Schema Definitions**: Create detailed schema definitions for every entity and its variants\n3. **Maintain Type Naming Conventions**: Follow the established type naming patterns\n4. **Ensure Schema Completeness**: Verify that ALL entities in the Prisma schema have corresponding schema definitions\n5. **Create Type Variants**: Define all necessary type variants for each entity (.ICreate, .IUpdate, .ISummary, etc.)\n6. **Document Thoroughly**: Provide comprehensive descriptions for all schema definitions\n7. **Validate Consistency**: Ensure schema definitions align with API operations\n8. **Use Named References Only**: NEVER use inline/anonymous object definitions - ALL object types must be defined as named types in the schemas record and referenced using $ref\n\n## 3. Schema Design Principles\n\n### 3.1. Type Naming Conventions\n\n- **Main Entity Types**: Use `IEntityName` format\n- **Operation-Specific Types**:\n  - `IEntityName.ICreate`: Request body for creation operations (POST)\n  - `IEntityName.IUpdate`: Request body for update operations (PUT or PATCH)\n  - `IEntityName.ISummary`: Simplified response version with essential properties\n  - `IEntityName.IRequest`: Request parameters for list operations (search/filter/pagination)\n  - `IEntityName.IAbridge`: Intermediate view with more detail than Summary but less than full entity\n  - `IEntityName.IInvert`: Alternative representation of an entity from a different perspective\n- **Container Types**: \n  - `IPageIEntityName`: Paginated results container (use the standard IPage structure)\n\n### 3.2. Schema Definition Requirements\n\n- **Completeness**: Include ALL properties from the Prisma schema for each entity\n- **Type Accuracy**: Map Prisma types to appropriate OpenAPI types and formats\n- **Required Fields**: Accurately mark required fields based on Prisma schema constraints\n- **Relationships**: Properly handle entity relationships (references to other entities)\n- **Enumerations**: Define all enum types referenced in entity schemas\n- **Detailed Documentation**: \n  - Schema descriptions must reference related Prisma schema table comments\n  - Property descriptions must reference related Prisma schema column comments\n  - All descriptions must be organized in multiple paragraphs for better readability\n- **Named References Only**: \n  - Every object type MUST be defined as a named type in the schemas record\n  - NEVER use inline/anonymous object definitions anywhere in the schema\n  - All property types that are objects must use $ref to reference a named type\n  - This applies to EVERY object in the schema, including nested objects and arrays of objects\n\n### 3.3. 🔴 CRITICAL Security Requirements\n\n#### Response Types - NEVER expose sensitive fields:\n- **Password fields**: NEVER include fields like `password`, `hashed_password`, `encrypted_password`, `salt`, etc. in ANY response type\n- **Security tokens**: NEVER expose `refresh_token`, `api_key`, `secret_key`, or similar security credentials\n- **Internal system fields**: Avoid exposing internal implementation details like `password_reset_token`, `email_verification_code`\n- **Sensitive personal data**: Be cautious with fields containing sensitive information based on your domain\n\n**Example of FORBIDDEN response properties**:\n```typescript\n// ❌ NEVER include these in response types\ninterface IUser {\n  id: string;\n  email: string;\n  hashed_password: string;  // FORBIDDEN\n  salt: string;             // FORBIDDEN\n  refresh_token: string;    // FORBIDDEN\n  api_secret: string;       // FORBIDDEN\n}\n\n// ✅ Correct response type\ninterface IUser {\n  id: string;\n  email: string;\n  name: string;\n  created_at: string;\n  // Password and security fields are intentionally omitted\n}\n```\n\n#### Request Types - NEVER accept actor IDs directly:\n- **Actor identification**: NEVER accept fields like `user_id`, `member_id`, `creator_id`, `author_id` in request bodies\n- **Authentication source**: The authenticated user\'s identity comes from the authentication decorator, NOT from request body\n- **Security principle**: Clients should NEVER be able to specify "who they are" - this must come from verified authentication\n\n**Example of FORBIDDEN request properties**:\n```typescript\n// ❌ NEVER accept actor IDs in request types\ninterface IPostCreate {\n  title: string;\n  content: string;\n  author_id: string;      // FORBIDDEN - comes from authentication\n  created_by: string;     // FORBIDDEN - comes from authentication\n}\n\n// ✅ Correct request type\ninterface IPostCreate {\n  title: string;\n  content: string;\n  category_id: string;    // OK - selecting a category\n  // author_id will be set by the server using authenticated user info\n}\n```\n\n**Why this matters**:\n1. **Security**: Prevents users from impersonating others or claiming false ownership\n2. **Data integrity**: Ensures the true actor is recorded for audit trails\n3. **Authorization**: Enables proper ownership verification in provider functions\n\n**Remember**: The authenticated user information is provided by the decorator at the controller level and passed to the provider function - it should NEVER come from client input.\n\n### 3.4. Standard Type Definitions\n\nFor paginated results, use the standard `IPage<T>` interface:\n\n```typescript\n/**\n * A page.\n *\n * Collection of records with pagination information.\n *\n * @author Samchon\n */\nexport interface IPage<T extends object> {\n  /**\n   * Page information.\n   */\n  pagination: IPage.IPagination;\n\n  /**\n   * List of records.\n   */\n  data: T[];\n}\nexport namespace IPage {\n  /**\n   * Page information.\n   */\n  export interface IPagination {\n    /**\n     * Current page number.\n     */\n    current: number & tags.Type<"uint32">;\n\n    /**\n     * Limitation of records per a page.\n     *\n     * @default 100\n     */\n    limit: number & tags.Type<"uint32">;\n\n    /**\n     * Total records in the database.\n     */\n    records: number & tags.Type<"uint32">;\n\n    /**\n     * Total pages.\n     *\n     * Equal to {@link records} / {@link limit} with ceiling.\n     */\n    pages: number & tags.Type<"uint32">;\n  }\n\n  /**\n   * Page request data\n   */\n  export interface IRequest {\n    /**\n     * Page number.\n     */\n    page?: null | (number & tags.Type<"uint32">);\n\n    /**\n     * Limitation of records per a page.\n     *\n     * @default 100\n     */\n    limit?: null | (number & tags.Type<"uint32">);\n  }\n}\n```\n\n## 4. Implementation Strategy\n\n### 4.1. Comprehensive Entity Identification\n\n1. **Extract All Entity References**:\n   - Analyze all API operation paths for entity identifiers\n   - Examine request and response bodies in API operations\n   - Review the Prisma schema to identify ALL entities\n\n2. **Create Entity Tracking System**:\n   - List ALL entities from the Prisma schema\n   - Cross-reference with entities mentioned in API operations\n   - Identify any entities that might be missing schema definitions\n\n### 4.2. Schema Definition Process\n\n1. **For Each Entity**:\n   - Define the main entity schema (`IEntityName`)\n   - Create all necessary variant types based on API operations\n   - Ensure all properties are documented with descriptions from Prisma schema\n   - Mark required fields based on Prisma schema constraints\n   - **CRITICAL**: Apply security filtering - remove sensitive fields from response types\n\n2. **For Relationship Handling**:\n   - Identify all relationships from the ERD and Prisma schema\n   - Define appropriate property types for relationships (IDs, nested objects, arrays)\n   - Document relationship constraints and cardinality\n   - **IMPORTANT**: For "belongs to" relationships, never accept the owner ID in requests\n\n3. **For Variant Types**:\n   - Create `.ICreate` types with appropriate required/optional fields for creation\n     - **NEVER include**: creator_id, author_id, user_id, created_by fields\n     - These fields will be populated from authenticated user context\n   - Define `.IUpdate` types with all fields made optional for updates\n     - **NEVER include**: updater_id, modified_by, last_updated_by fields\n     - **NEVER allow**: changing ownership fields like author_id or creator_id\n   - Build `.ISummary` types with essential fields for list views\n     - Include only safe, public-facing properties\n   - Define `.IRequest` types with search/filter/sort parameters\n     - May include filters like "my_posts_only" but not "user_id" parameters\n\n4. **Security Checklist for Each Type**:\n   - ✓ No password or hash fields in any response type\n   - ✓ No security tokens or keys in any response type\n   - ✓ No actor ID fields in any request type\n   - ✓ No internal system fields exposed in responses\n   - ✓ Ownership fields are read-only (never in request types)\n\n### 4.3. Schema Completeness Verification\n\n1. **Entity Coverage Check**:\n   - Verify every entity in the Prisma schema has at least one schema definition\n   - Check that all entities referenced in API operations have schema definitions\n\n2. **Property Coverage Check**:\n   - Ensure all properties from the Prisma schema are included in entity schemas\n   - Verify property types align with Prisma schema definitions\n\n3. **Variant Type Verification**:\n   - Confirm necessary variant types exist based on API operations\n   - Ensure variant types have appropriate property subsets and constraints\n\n## 5. Documentation Quality Requirements\n\n### 5.1. **Schema Type Descriptions**\n- Must reference related Prisma schema table description comments\n- Must be extremely detailed and comprehensive\n- Must be organized in multiple paragraphs\n- Should explain the entity\'s role in the business domain\n- Should describe relationships with other entities\n\n### 5.2. **Property Descriptions**\n- Must reference related Prisma schema column description comments\n- Must explain the purpose, constraints, and format of each property\n- Should note business rules that apply to the property\n- Should provide examples when helpful\n- Should use multiple paragraphs for complex properties\n\n## 6. Output Format\n\nYour output should be the complete `schemas` record of the OpenAPI document:\n\n```typescript\nconst schemas: Record<string, AutoBeOpenApi.IJsonSchemaDescriptive> = {\n  // Main entity types\n  IEntityName: { \n    type: "object", \n    properties: {\n      propertyName: {\n        type: "string",\n        description: "Detailed property description referencing Prisma schema column comments.\\n\\nMultiple paragraphs where appropriate."\n      }\n      // ...more properties\n      // SECURITY: Never include password, hashed_password, salt, or other sensitive fields in response types\n    },\n    required: [...],\n    description: "Extremely detailed explanation about IEntityName referencing Prisma schema table comments.\\n\\nMultiple paragraphs focusing on different aspects of the entity.",\n  },\n  // Variant types\n  "IEntityName.ICreate": { \n    // SECURITY: Never include author_id, creator_id, user_id - these come from authentication context\n    ... \n  },\n  "IEntityName.IUpdate": { \n    // SECURITY: Never allow updating ownership fields like author_id or creator_id\n    ... \n  },\n  "IEntityName.ISummary": { ... },\n  "IEntityName.IRequest": { ... },\n  \n  // Repeat for ALL entities\n  \n  // Standard types\n  "IPage": { ... },\n  "IPage.IPagination": { ... },\n  "IPage.IRequest": { ... },\n  \n  // Enumerations\n  "EEnumName": { ... }\n}\n```\n\n## 7. Critical Success Factors\n\n### 7.1. Absolute Completeness Principles\n\n- **Process ALL Entities**: EVERY entity defined in the Prisma schema MUST have corresponding schema definitions.\n- **Complete Property Coverage**: ALL properties of each entity MUST be included in schema definitions.\n- **Variant Type Comprehensiveness**: ALL necessary variant types MUST be defined based on API operations.\n- **No Simplification**: Complex entities or relationships MUST be faithfully represented without simplification.\n- **Verification of Completeness**: Before final output, verify that ALL entities and properties have been defined.\n\n### 7.2. High-Volume Processing Strategy\n\n- **Batch Processing**: If there are many entities, process them in groups, but ALL groups MUST be completed.\n- **No Prioritization**: ALL entities and their properties have equal importance and must be processed.\n- **Systematic Approach**: Use a methodical approach to ensure no entity or property is overlooked.\n- **Detailed Tracking**: Maintain a tracking system to verify completeness of schema definitions.\n\n### 7.3. Critical Warnings\n\n- **Partial Implementation Prohibited**: "Defining schemas for only some entities and omitting others" is a CRITICAL ERROR.\n- **Property Omission Prohibited**: "Including only some properties of an entity" is a SERIOUS ERROR.\n- **No Simplification**: "Simplifying complex entities or relationships" is NOT ACCEPTABLE.\n- **Ignore Capacity Limitations**: Processing only some entities due to their quantity is a SERIOUS ERROR.\n- **Named Types Required**: Using inline/anonymous object definitions instead of named type references ($ref) is a CRITICAL ERROR. EVERY object type must be defined in the schemas record and referenced by name.\n- **Security Violations**: Including password fields in responses or actor IDs in requests is a CRITICAL SECURITY ERROR.\n- **Authentication Bypass**: Accepting user identity from request body instead of authentication context is a CRITICAL SECURITY ERROR.\n\n## 8. Execution Process\n\n1. **Initialization**:\n   - Analyze all input data (API operations, Prisma schema, ERD)\n   - Create a complete inventory of entities and their relationships\n\n2. **Schema Development**:\n   - Systematically define schema definitions for each entity and its variants\n   - Document all definitions and properties thoroughly\n\n3. **Verification**:\n   - Validate completeness against the Prisma schema\n   - Verify consistency with API operations\n   - Ensure all relationships are properly handled\n\n4. **Output Generation**:\n   - Produce the complete `schemas` record in the required format\n   - Verify the output meets all quality and completeness requirements\n\nRemember that your role is CRITICAL to the success of the entire API design process. The schemas you define will be the foundation for ALL data exchange in the API. Thoroughness, accuracy, and completeness are your highest priorities.\n\n## 9. Integration with Previous Phases\n\n- Ensure your schema definitions align perfectly with the API operations defined in Phase 2\n- Reference the same entities and property names used in the API paths from Phase 1\n- Maintain consistency in naming, typing, and structure throughout the entire API design\n\n## 10. Final Output Format\n\nYour final output should be the complete `schemas` record that can be directly integrated with the API operations from Phase 2 to form a complete `AutoBeOpenApi.IDocument` object.\n\nAlways aim to create schema definitions that are intuitive, well-documented, and accurately represent the business domain. Your schema definitions should meet ALL business requirements while being extensible and maintainable. Remember to define schemas for EVERY SINGLE independent entity table in the Prisma schema. NO ENTITY OR PROPERTY SHOULD BE OMITTED FOR ANY REASON.'
+}, ...transformInterfaceAssetHistories(state), {
+    type: "assistantMessage",
+    id: v4(),
+    created_at: (new Date).toISOString(),
+    text: [ "Here is the list of API operations you have to implement its types:", "", "```json", JSON.stringify(operations), "```" ].join("\n")
+} ];
+
+async function orchestrateInterfaceSchemas(ctx, operations, capacity = 12) {
+    const typeNames = new Set;
+    for (const op of operations) {
+        if (op.requestBody !== null) typeNames.add(op.requestBody.typeName);
+        if (op.responseBody !== null) typeNames.add(op.responseBody.typeName);
+    }
+    const matrix = divideArray({
+        array: Array.from(typeNames),
+        capacity
+    });
+    let progress = 0;
+    const x = {};
+    for (const y of await Promise.all(matrix.map((async it => {
+        const row = await divideAndConquer(ctx, operations, it, 3, (count => {
+            progress += count;
+        }));
+        ctx.dispatch({
+            type: "interfaceSchemas",
+            schemas: row,
+            completed: progress,
+            total: typeNames.size,
+            step: ctx.state().analyze?.step ?? 0,
+            created_at: (new Date).toISOString()
+        });
+        return row;
+    })))) {
+        Object.assign(x, y);
+    }
+    return x;
+}
+
+async function divideAndConquer(ctx, operations, typeNames, retry, progress) {
+    const remained = new Set(typeNames);
+    const schemas = {};
+    for (let i = 0; i < retry; ++i) {
+        if (remained.size === 0) break;
+        const before = remained.size;
+        const newbie = await forceRetry((() => process$4(ctx, operations, schemas, remained)));
+        for (const key of Object.keys(newbie)) {
+            schemas[key] = newbie[key];
+            remained.delete(key);
+        }
+        if (before - remained.size !== 0) progress(before - remained.size);
+    }
+    return schemas;
+}
+
+async function process$4(ctx, operations, oldbie, remained) {
+    const pointer = {
+        value: null
+    };
+    const agentica = new MicroAgentica({
+        model: ctx.model,
+        vendor: ctx.vendor,
+        config: {
+            ...ctx.config ?? {},
+            executor: {
+                describe: null
+            }
+        },
+        histories: transformInterfaceSchemaHistories(ctx.state(), operations),
+        controllers: [ createApplication$9({
+            model: ctx.model,
+            build: async next => {
+                pointer.value ?? (pointer.value = {});
+                Object.assign(pointer.value, next);
+            },
+            pointer
+        }) ]
+    });
+    enforceToolCall(agentica);
+    const already = Object.keys(oldbie);
+    await agentica.conversate([ "Make type components please.", "", "Here is the list of request/response bodies' type names from", "OpenAPI operations. Make type components of them. If more object", "types are required during making the components, please make them", "too.", "", ...Array.from(remained).map((k => `- \`${k}\``)), ...already.length !== 0 ? [ "", "> By the way, here is the list of components schemas what you've", "> already made. So, you don't need to make them again.", ">", ...already.map((k => `> - \`${k}\``)) ] : [] ].join("\n")).finally((() => {
+        const tokenUsage = agentica.getTokenUsage();
+        ctx.usage().record(tokenUsage, [ "interface" ]);
+    }));
+    if (pointer.value === null) {
+        throw new Error("Failed to create components.");
+    }
+    return OpenApiV3_1Emender.convertComponents({
+        schemas: pointer.value
+    }).schemas ?? {};
+}
+
+function createApplication$9(props) {
+    assertSchemaModel(props.model);
+    const application = collection$a[props.model];
+    return {
+        protocol: "class",
+        name: "interface",
+        application,
+        execute: {
+            makeComponents: async next => {
+                await props.build(next.schemas);
+            }
+        }
+    };
+}
+
+const claude$a = {
+    model: "claude",
+    options: {
+        reference: true,
+        separate: null
+    },
+    functions: [ {
+        name: "makeComponents",
+        parameters: {
+            description: " Properties containing components to generate.\n\n------------------------------\n\nCurrent Type: {@link IAutoBeInterfaceSchemaApplication.IProps}",
+            type: "object",
+            properties: {
+                schemas: {
+                    description: 'Complete set of schema components for the OpenAPI specification.\n\nThis property contains comprehensive type definitions for all entities in\nthe system. It is the central repository of all named schema types that\nwill be used throughout the API specification.\n\nCRITICAL REQUIREMENT: All object types MUST be defined as named types in\nthe components.schemas section. Inline anonymous object definitions are\nstrictly prohibited.\n\nThis components object should include:\n\n- Main entity types (IEntityName)\n- Operation-specific variants (.ICreate, .IUpdate, .ISummary, etc.)\n- Container types (IPage<T> for pagination)\n- Enumeration types\n\nAll schema definitions must include detailed descriptions that reference\nthe original Prisma schema comments and thoroughly document each\nproperty. Every property that references an object must use a $ref to a\nnamed type in the components.schemas section. This applies to all objects\nin request bodies, response bodies, and properties that are objects or\narrays of objects.\n\nExample structure:\n\n```typescript\n{\n  schemas: {\n    IUser: {\n      type: "object",\n      properties: {\n        id: { type: "string", format: "uuid" },\n        email: { type: "string", format: "email" },\n        profile: { "$ref": "#/components/schemas/IUserProfile" }\n      },\n      required: ["id", "email"],\n      description: "User entity representing system account holders..."\n    },\n    "IUser.ICreate": { ... },\n    // Additional schemas\n  }\n}\n```',
+                    $ref: "#/$defs/RecordstringAutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema"
+                }
+            },
+            required: [ "schemas" ],
+            additionalProperties: false,
+            $defs: {
+                "RecordstringAutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema": {
+                    description: "Construct a type with a set of properties K of type T",
+                    type: "object",
+                    properties: {},
+                    required: [],
+                    additionalProperties: {
+                        $ref: "#/$defs/AutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema"
+                    }
+                },
+                "AutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema": {
+                    description: "Descriptive type schema info.\n\n`AutoBeOpenApi.IJsonSchemaDescriptive` is a type schema info of the OpenAPI\nGenerative, but it has a `description` property which is required.\n\n`AutoBeOpenApi.IJsonSchemaDescriptive` basically follows the JSON schema\nspecification of OpenAPI v3.1, but a little bit shrunk to remove ambiguous\nand duplicated expressions of OpenAPI v3.1 for the convenience, clarity,\nand AI generation.\n\nCRITICAL INSTRUCTIONS FOR OPTIMAL AI GENERATION:\n\nWhen creating descriptions for components, types, and properties:\n\n1. ALWAYS refer to and incorporate the description comments from the\n   corresponding Prisma DB schema tables and columns. The descriptions\n   should match the style, level of detail, and terminology used in the\n   Prisma schema.\n2. ALL descriptions MUST be organized into MULTIPLE PARAGRAPHS separated by\n   line breaks. Single-paragraph descriptions should be avoided.\n3. Descriptions should comprehensively cover:\n\n   - The purpose and business meaning of the type or property\n   - Relationships to other entities\n   - Validation rules, constraints, and edge cases\n   - Usage context and examples when helpful\n4. For each property of an object type, ensure its description reflects the\n   corresponding column description in the Prisma DB schema, maintaining\n   the same level of detail and terminology\n5. Descriptions should be so detailed and clear that anyone reading them can\n   fully understand the type or property without needing to reference any\n   other documentation",
+                    type: "object",
+                    properties: {
+                        description: {
+                            description: "Description about the type.\n\nCRITICAL: This description MUST be extensively detailed and MUST\nreference and align with the description comments from the\ncorresponding Prisma DB schema tables and columns.\n\nThe description MUST be organized into MULTIPLE PARAGRAPHS (separated\nby line breaks) based on different aspects of the type:\n\n- The purpose and business meaning of the type\n- Relationships to other entities in the system\n- Validation rules, constraints, and edge cases\n- Usage context and examples when helpful\n\nThis structured approach improves readability and helps readers better\nunderstand the type's various characteristics and use cases. The\ndescription should be so comprehensive that anyone reading it can fully\nunderstand the type without needing to reference other documentation.\n\n> MUST be written in English. Never use other languages.",
+                            type: "string"
+                        }
+                    },
+                    required: [ "description" ]
+                }
+            }
+        },
+        description: "Generate OpenAPI components containing named schema types.\n\nThis method receives a complete set of schema components and integrates\nthem into the final OpenAPI specification. It processes all entity schemas,\ntheir variants, and related type definitions to ensure a comprehensive and\nconsistent API design.\n\nThe provided components should include schemas for all entities identified\nin the previous phases of API path/method definition and operation\ncreation. This ensures that the final OpenAPI document has complete type\ncoverage for all operations.\n\nCRITICAL: All schema definitions must follow the established naming\nconventions (IEntityName, IEntityName.ICreate, etc.) and must be thoroughly\ndocumented with descriptions that reference the original Prisma schema\ncomments.",
+        validate: (() => {
+            const _io0 = input => "object" === typeof input.schemas && null !== input.schemas && false === Array.isArray(input.schemas) && _io1(input.schemas);
+            const _io1 = input => Object.keys(input).every((key => {
+                const value = input[key];
+                if (undefined === value) return true;
+                return "object" === typeof value && null !== value && _io2(value);
+            }));
+            const _io2 = input => "string" === typeof input.description;
+            const _vo0 = (input, _path, _exceptionable = true) => [ ("object" === typeof input.schemas && null !== input.schemas && false === Array.isArray(input.schemas) || _report(_exceptionable, {
+                path: _path + ".schemas",
+                expected: "Record<string, AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>>",
+                value: input.schemas
+            })) && _vo1(input.schemas, _path + ".schemas", _exceptionable) || _report(_exceptionable, {
+                path: _path + ".schemas",
+                expected: "Record<string, AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>>",
+                value: input.schemas
+            }) ].every((flag => flag));
+            const _vo1 = (input, _path, _exceptionable = true) => [ false === _exceptionable || Object.keys(input).map((key => {
+                const value = input[key];
+                if (undefined === value) return true;
+                return ("object" === typeof value && null !== value || _report(_exceptionable, {
+                    path: _path + __typia_transform__accessExpressionAsString._accessExpressionAsString(key),
+                    expected: "AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>",
+                    value
+                })) && _vo2(value, _path + __typia_transform__accessExpressionAsString._accessExpressionAsString(key), _exceptionable) || _report(_exceptionable, {
+                    path: _path + __typia_transform__accessExpressionAsString._accessExpressionAsString(key),
+                    expected: "AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>",
+                    value
+                });
+            })).every((flag => flag)) ].every((flag => flag));
+            const _vo2 = (input, _path, _exceptionable = true) => [ "string" === typeof input.description || _report(_exceptionable, {
+                path: _path + ".description",
+                expected: "string",
+                value: input.description
+            }) ].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: "IAutoBeInterfaceSchemaApplication.IProps",
+                        value: input
+                    })) && _vo0(input, _path + "", true) || _report(true, {
+                        path: _path + "",
+                        expected: "IAutoBeInterfaceSchemaApplication.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
+                };
+            };
+        })()
+    } ]
+};
+
+const collection$a = {
+    chatgpt: {
+        model: "chatgpt",
+        options: {
+            reference: true,
+            strict: false,
+            separate: null
+        },
+        functions: [ {
+            name: "makeComponents",
+            parameters: {
+                description: ' Properties containing components to generate.\n\n------------------------------\n\nCurrent Type: {@link IAutoBeInterfaceSchemaApplication.IProps}\n\n### Description of {@link schemas} property:\n\n> Complete set of schema components for the OpenAPI specification.\n> \n> This property contains comprehensive type definitions for all entities in\n> the system. It is the central repository of all named schema types that\n> will be used throughout the API specification.\n> \n> CRITICAL REQUIREMENT: All object types MUST be defined as named types in\n> the components.schemas section. Inline anonymous object definitions are\n> strictly prohibited.\n> \n> This components object should include:\n> \n> - Main entity types (IEntityName)\n> - Operation-specific variants (.ICreate, .IUpdate, .ISummary, etc.)\n> - Container types (IPage<T> for pagination)\n> - Enumeration types\n> \n> All schema definitions must include detailed descriptions that reference\n> the original Prisma schema comments and thoroughly document each\n> property. Every property that references an object must use a $ref to a\n> named type in the components.schemas section. This applies to all objects\n> in request bodies, response bodies, and properties that are objects or\n> arrays of objects.\n> \n> Example structure:\n> \n> ```typescript\n> {\n>   schemas: {\n>     IUser: {\n>       type: "object",\n>       properties: {\n>         id: { type: "string", format: "uuid" },\n>         email: { type: "string", format: "email" },\n>         profile: { "$ref": "#/components/schemas/IUserProfile" }\n>       },\n>       required: ["id", "email"],\n>       description: "User entity representing system account holders..."\n>     },\n>     "IUser.ICreate": { ... },\n>     // Additional schemas\n>   }\n> }\n> ```',
+                type: "object",
+                properties: {
+                    schemas: {
+                        $ref: "#/$defs/RecordstringAutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema"
+                    }
+                },
+                required: [ "schemas" ],
+                additionalProperties: false,
+                $defs: {
+                    "RecordstringAutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema": {
+                        description: "Construct a type with a set of properties K of type T",
+                        type: "object",
+                        properties: {},
+                        required: [],
+                        additionalProperties: {
+                            $ref: "#/$defs/AutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema"
+                        }
+                    },
+                    "AutoBeOpenApi.IJsonSchemaDescriptiveAutoBeOpenApi.IJsonSchema": {
+                        description: "Descriptive type schema info.\n\n`AutoBeOpenApi.IJsonSchemaDescriptive` is a type schema info of the OpenAPI\nGenerative, but it has a `description` property which is required.\n\n`AutoBeOpenApi.IJsonSchemaDescriptive` basically follows the JSON schema\nspecification of OpenAPI v3.1, but a little bit shrunk to remove ambiguous\nand duplicated expressions of OpenAPI v3.1 for the convenience, clarity,\nand AI generation.\n\nCRITICAL INSTRUCTIONS FOR OPTIMAL AI GENERATION:\n\nWhen creating descriptions for components, types, and properties:\n\n1. ALWAYS refer to and incorporate the description comments from the\n   corresponding Prisma DB schema tables and columns. The descriptions\n   should match the style, level of detail, and terminology used in the\n   Prisma schema.\n2. ALL descriptions MUST be organized into MULTIPLE PARAGRAPHS separated by\n   line breaks. Single-paragraph descriptions should be avoided.\n3. Descriptions should comprehensively cover:\n\n   - The purpose and business meaning of the type or property\n   - Relationships to other entities\n   - Validation rules, constraints, and edge cases\n   - Usage context and examples when helpful\n4. For each property of an object type, ensure its description reflects the\n   corresponding column description in the Prisma DB schema, maintaining\n   the same level of detail and terminology\n5. Descriptions should be so detailed and clear that anyone reading them can\n   fully understand the type or property without needing to reference any\n   other documentation",
+                        type: "object",
+                        properties: {
+                            description: {
+                                description: "Description about the type.\n\nCRITICAL: This description MUST be extensively detailed and MUST\nreference and align with the description comments from the\ncorresponding Prisma DB schema tables and columns.\n\nThe description MUST be organized into MULTIPLE PARAGRAPHS (separated\nby line breaks) based on different aspects of the type:\n\n- The purpose and business meaning of the type\n- Relationships to other entities in the system\n- Validation rules, constraints, and edge cases\n- Usage context and examples when helpful\n\nThis structured approach improves readability and helps readers better\nunderstand the type's various characteristics and use cases. The\ndescription should be so comprehensive that anyone reading it can fully\nunderstand the type without needing to reference other documentation.\n\n> MUST be written in English. Never use other languages.",
+                                type: "string"
+                            }
+                        },
+                        required: [ "description" ]
+                    }
+                }
+            },
+            description: "Generate OpenAPI components containing named schema types.\n\nThis method receives a complete set of schema components and integrates\nthem into the final OpenAPI specification. It processes all entity schemas,\ntheir variants, and related type definitions to ensure a comprehensive and\nconsistent API design.\n\nThe provided components should include schemas for all entities identified\nin the previous phases of API path/method definition and operation\ncreation. This ensures that the final OpenAPI document has complete type\ncoverage for all operations.\n\nCRITICAL: All schema definitions must follow the established naming\nconventions (IEntityName, IEntityName.ICreate, etc.) and must be thoroughly\ndocumented with descriptions that reference the original Prisma schema\ncomments.",
+            validate: (() => {
+                const _io0 = input => "object" === typeof input.schemas && null !== input.schemas && false === Array.isArray(input.schemas) && _io1(input.schemas);
+                const _io1 = input => Object.keys(input).every((key => {
+                    const value = input[key];
+                    if (undefined === value) return true;
+                    return "object" === typeof value && null !== value && _io2(value);
+                }));
+                const _io2 = input => "string" === typeof input.description;
+                const _vo0 = (input, _path, _exceptionable = true) => [ ("object" === typeof input.schemas && null !== input.schemas && false === Array.isArray(input.schemas) || _report(_exceptionable, {
+                    path: _path + ".schemas",
+                    expected: "Record<string, AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>>",
+                    value: input.schemas
+                })) && _vo1(input.schemas, _path + ".schemas", _exceptionable) || _report(_exceptionable, {
+                    path: _path + ".schemas",
+                    expected: "Record<string, AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>>",
+                    value: input.schemas
+                }) ].every((flag => flag));
+                const _vo1 = (input, _path, _exceptionable = true) => [ false === _exceptionable || Object.keys(input).map((key => {
+                    const value = input[key];
+                    if (undefined === value) return true;
+                    return ("object" === typeof value && null !== value || _report(_exceptionable, {
+                        path: _path + __typia_transform__accessExpressionAsString._accessExpressionAsString(key),
+                        expected: "AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>",
+                        value
+                    })) && _vo2(value, _path + __typia_transform__accessExpressionAsString._accessExpressionAsString(key), _exceptionable) || _report(_exceptionable, {
+                        path: _path + __typia_transform__accessExpressionAsString._accessExpressionAsString(key),
+                        expected: "AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>",
+                        value
+                    });
+                })).every((flag => flag)) ].every((flag => flag));
+                const _vo2 = (input, _path, _exceptionable = true) => [ "string" === typeof input.description || _report(_exceptionable, {
                     path: _path + ".description",
                     expected: "string",
                     value: input.description
-                }), "string" === typeof input.typeName || _report(_exceptionable, {
-                    path: _path + ".typeName",
-                    expected: "string",
-                    value: input.typeName
                 }) ].every((flag => flag));
-                const _vu0 = (input, _path, _exceptionable = true) => (() => {
-                    if ("number" === input.type) return _vo4(input, _path, _exceptionable); else if ("integer" === input.type) return _vo3(input, _path, _exceptionable); else if ("string" === input.type) return _vo5(input, _path, _exceptionable); else return _report(_exceptionable, {
-                        path: _path,
-                        expected: "(AutoBeOpenApi.IJsonSchema.INumber | AutoBeOpenApi.IJsonSchema.IInteger | AutoBeOpenApi.IJsonSchema.IString)",
-                        value: input
-                    });
-                })();
                 const __is = input => "object" === typeof input && null !== input && _io0(input);
                 let errors;
                 let _report;
@@ -3877,11 +4217,11 @@ const collection$a = {
                         _report = __typia_transform__validateReport._validateReport(errors);
                         ((input, _path, _exceptionable = true) => ("object" === typeof input && null !== input || _report(true, {
                             path: _path + "",
-                            expected: "IMakeOperationProps",
+                            expected: "IAutoBeInterfaceSchemaApplication.IProps",
                             value: input
                         })) && _vo0(input, _path + "", true) || _report(true, {
                             path: _path + "",
-                            expected: "IMakeOperationProps",
+                            expected: "IAutoBeInterfaceSchemaApplication.IProps",
                             value: input
                         }))(input, "$input", true);
                         const success = 0 === errors.length;
@@ -3916,18 +4256,22 @@ const orchestrateInterface = ctx => async props => {
         reason: props.reason,
         step: ctx.state().analyze?.step ?? 0
     });
-    const init = await orchestrateInterfaceEndpoints(ctx);
+    const init = await orchestrateInterfaceGroups(ctx);
     if (init.type === "assistantMessage") {
         ctx.dispatch(init);
         ctx.histories().push(init);
         return init;
     } else ctx.dispatch(init);
-    const operations = await orchestrateInterfaceOperations(ctx, init.endpoints);
+    const endpoints = await orchestrateInterfaceEndpoints(ctx, init.groups);
+    const operations = await orchestrateInterfaceOperations(ctx, endpoints);
     const document = {
         operations,
-        components: await orchestrateInterfaceComponents(ctx, operations)
+        components: {
+            authorization: ctx.state().analyze?.roles ?? [],
+            schemas: await orchestrateInterfaceSchemas(ctx, operations)
+        }
     };
-    document.components = await orchestrateInterfaceComplement(ctx, document);
+    document.components.schemas = await orchestrateInterfaceComplement(ctx, document);
     const result = {
         type: "interface",
         id: v4(),
@@ -6813,7 +7157,7 @@ const transformRealizeAuthorizationCorrectHistories = (ctx, auth, templateFiles,
     id: v4(),
     created_at: (new Date).toISOString(),
     type: "systemMessage",
-    text: '# NestJS Authentication Provider & Decorator Generation AI Agent  \n\nYou are a world-class NestJS expert and TypeScript developer. Your role is to automatically generate Provider functions and Decorators for JWT authentication based on given Role information and Prisma Schema.  \n\n## Core Mission  \n\nGenerate authentication Provider and Decorator code specialized for specific Roles based on Role information provided by users.  \n\n## Input Information  \n\n- **Role Name**: The authentication role to generate (e.g., admin, user, manager, etc.)  \n- **Prisma Schema**: Database table information.\n\n## Code Generation Rules  \n\n### 1. Provider Function Generation Rules  \n\n- Function name: `{role}Authorize` format (e.g., adminAuthorize, userAuthorize)  \n- Must use the `jwtAuthorize` function for JWT token verification  \n- Verify payload type and check if `payload.type` matches the correct role  \n- Query database using `MyGlobal.prisma.{tableName}` format to fetch **only the authorization model itself** - do not include relations or business logic models (no `include` statements for profile, etc.)  \n- Verify that the user actually exists in the database  \n- Function return type should be `{Role}Payload` interface  \n- Return the `payload` variable whenever feasible in provider functions.  \n- **Always check the Prisma schema for validation columns (e.g., `deleted_at`, status fields) within the authorization model and include them in the `where` clause to ensure the user is valid and active.**  \n\n### 2. Payload Interface Generation Rules  \n\n- Interface name: `{Role}Payload` format (e.g., AdminPayload, UserPayload)  \n- Required fields:  \n  - `id: string & tags.Format<"uuid">`: User ID (UUID format)  \n  - `type: "{role}"`: Discriminator for role identification  \n- Additional fields should be generated according to Role characteristics and "Prisma Schema"  \n\n### 3. Decorator Generation Rules  \n\n- Decorator name: `{Role}Auth` format (e.g., AdminAuth, UserAuth)  \n- Use SwaggerCustomizer to add bearer token security schema to API documentation  \n- Use createParamDecorator to implement actual authentication logic  \n- Use Singleton pattern to manage decorator instances  \n\n### 4. Code Style and Structure\n\n- Comply with TypeScript strict mode  \n- Utilize NestJS Exception classes (ForbiddenException, UnauthorizedException)  \n- Ensure type safety using typia tags  \n- Add appropriate JSDoc comments  \n\n## Reference Functions and Examples  \n\n### JWT Authentication Function  \n\n```typescript\nimport { ForbiddenException, UnauthorizedException } from "@nestjs/common";\nimport jwt from "jsonwebtoken";\n\nimport { MyGlobal } from "../MyGlobal";\n\nexport function jwtAuthorize(props: {\n  request: {\n    headers: { authorization?: string };\n  };\n}) {\n  if (!props.request.headers.authorization)\n    throw new ForbiddenException("No token value exists");\n  else if (\n    props.request.headers.authorization.startsWith(BEARER_PREFIX) === false\n  )\n    throw new UnauthorizedException("Invalid token");\n\n  // PARSE TOKEN\n  try {\n    const token: string = props.request.headers.authorization.substring(\n      BEARER_PREFIX.length,\n    );\n\n    const verified = jwt.verify(token, MyGlobal.env.JWT_SECRET_KEY);\n\n    return verified;\n  } catch {\n    throw new UnauthorizedException("Invalid token");\n  }\n}\n\nconst BEARER_PREFIX = "Bearer ";\n```  \n\n### Provider Function Example  \n\n```typescript\nimport { ForbiddenException } from "@nestjs/common";\n\nimport { MyGlobal } from "../../MyGlobal";\nimport { jwtAuthorize } from "./jwtAuthorize";\nimport { AdminPayload } from "../../decorators/payload/AdminPayload";\n\nexport async function adminAuthorize(request: {\n  headers: {\n    authorization?: string;\n  };\n}): Promise<AdminPayload> {\n  const payload: AdminPayload = jwtAuthorize({ request }) as AdminPayload;\n\n  if (payload.type !== "admin") {\n    throw new ForbiddenException(`You\'re not ${payload.type}`);\n  }\n\n  const admin = await MyGlobal.prisma.admins.findFirst({\n    where: {\n      id: payload.id,\n      user: {\n        deleted_at: null,\n        is_banned: false,\n      },\n    },\n  });\n\n  if (admin === null) {\n    throw new ForbiddenException("You\'re not enrolled");\n  }\n\n  return payload;\n}\n```  \n\n### Decorator Example\n\n```typescript\nimport { SwaggerCustomizer } from "@nestia/core";\nimport { ExecutionContext, createParamDecorator } from "@nestjs/common";\nimport { Singleton } from "tstl";\n\nimport { adminAuthorize } from "../providers/authorize/adminAuthorize";\n\nexport const AdminAuth =\n  (): ParameterDecorator =>\n  (\n    target: object,\n    propertyKey: string | symbol | undefined,\n    parameterIndex: number,\n  ): void => {\n    SwaggerCustomizer((props) => {\n      props.route.security ??= [];\n      props.route.security.push({\n        bearer: [],\n      });\n    })(target, propertyKey as string, undefined!);\n    singleton.get()(target, propertyKey, parameterIndex);\n  };\n\nconst singleton = new Singleton(() =>\n  createParamDecorator(async (_0: unknown, ctx: ExecutionContext) => {\n    const request = ctx.switchToHttp().getRequest();\n    return adminAuthorize(request);\n  })(),\n);\n```  \n\n### Decorator Type Example  \n\nIn case of the columns related to Date type like `created_at`, `updated_at`, `deleted_at`, must use the `string & tags.Format<\'date-time\'>` Type instead of Date type.  \n\n```typescript\nimport { tags } from "typia";\n\nexport interface AdminPayload {\n  /**\n   * Admin ID.\n   */\n  id: string & tags.Format<"uuid">;\n\n  /**\n   * Discriminator for the discriminated union type.\n   */\n  type: "admin";\n}\n```  \n\n## Output Format  \n\nYou must provide your response in a structured JSON format containing the following nested structure:  \n\n**provider**: An object containing the authentication Provider function configuration  \n\n- **name**: The name of the authentication Provider function in `{role}Authorize` format (e.g., adminAuthorize, userAuthorize). This function verifies JWT tokens and returns user information for the specified role.  \n- **code**: Complete TypeScript code for the authentication Provider function only. Must include JWT verification, role checking, database query logic, and proper import statements for the Payload interface.\n\n**decorator**: An object containing the authentication Decorator configuration  \n\n- **name**: The name of the Decorator to be generated in `{Role}Auth` format (e.g., AdminAuth, UserAuth). The decorator name used in Controller method parameters.  \n- **code**: Complete TypeScript code for the Decorator. Must include complete authentication decorator implementation using SwaggerCustomizer, createParamDecorator, and Singleton pattern.\n\n**decoratorType**: An object containing the Decorator Type configuration\n\n- **name**: The name of the Decorator Type in `{Role}Payload` format (e.g., AdminPayload, UserPayload). Used as the TypeScript type for the authenticated user data.\n- **code**: Complete TypeScript code for the Payload type interface. Must include proper field definitions with typia tags for type safety.\n\n## Work Process  \n\n1. Analyze the input Role name  \n2. Generate Provider function for the Role  \n3. Define Payload interface  \n4. Implement Decorator  \n5. Verify that all code follows example patterns  \n6. Generate response in specified format  \n\n## Quality Standards  \n\n- Ensure type safety  \n- Follow NestJS conventions  \n- Complete error handling  \n- Code reusability  \n- Complete documentation  \n\nWhen users provide Role information, generate complete and practical authentication code according to the above rules.'
+    text: '# NestJS Authentication Provider & Decorator Generation AI Agent  \n\nYou are a world-class NestJS expert and TypeScript developer. Your role is to automatically generate Provider functions and Decorators for JWT authentication based on given Role information and Prisma Schema.  \n\n## Core Mission  \n\nGenerate authentication Provider and Decorator code specialized for specific Roles based on Role information provided by users.  \n\n## Input Information  \n\n- **Role Name**: The authentication role to generate (e.g., admin, user, manager, etc.)  \n- **Prisma Schema**: Database table information.\n\n## File Structure\n\n**IMPORTANT: Understanding the file structure is crucial for correct import paths:**\n\n```\nsrc/\n├── MyGlobal.ts\n├── decorators/\n│   ├── AdminAuth.ts\n│   ├── UserAuth.ts\n│   └── payload/\n│       ├── AdminPayload.ts\n│       └── UserPayload.ts\n└── providers/\n    └── authorize/\n        ├── jwtAuthorize.ts      ← Shared JWT verification function\n        ├── adminAuthorize.ts    ← Same directory as jwtAuthorize\n        └── userAuthorize.ts     ← Same directory as jwtAuthorize\n```\n\n## Code Generation Rules  \n\n### 1. Provider Function Generation Rules  \n\n- Function name: `{role}Authorize` format (e.g., adminAuthorize, userAuthorize)  \n- Must use the `jwtAuthorize` function for JWT token verification  \n- **⚠️ CRITICAL: Import jwtAuthorize using `import { jwtAuthorize } from "./jwtAuthorize";` (NOT from "../../providers/authorize/jwtAuthorize" or any other path)**\n- Verify payload type and check if `payload.type` matches the correct role  \n- Query database using `MyGlobal.prisma.{tableName}` format to fetch **only the authorization model itself** - do not include relations or business logic models (no `include` statements for profile, etc.)  \n- Verify that the user actually exists in the database  \n- Function return type should be `{Role}Payload` interface  \n- Return the `payload` variable whenever feasible in provider functions.  \n- **Always check the Prisma schema for validation columns (e.g., `deleted_at`, status fields) within the authorization model and include them in the `where` clause to ensure the user is valid and active.**  \n\n### 2. Payload Interface Generation Rules  \n\n- Interface name: `{Role}Payload` format (e.g., AdminPayload, UserPayload)  \n- Required fields:  \n  - `id: string & tags.Format<"uuid">`: User ID (UUID format)  \n  - `type: "{role}"`: Discriminator for role identification  \n- Additional fields should be generated according to Role characteristics and "Prisma Schema"  \n\n### 3. Decorator Generation Rules  \n\n- Decorator name: `{Role}Auth` format (e.g., AdminAuth, UserAuth)  \n- Use SwaggerCustomizer to add bearer token security schema to API documentation  \n- Use createParamDecorator to implement actual authentication logic  \n- Use Singleton pattern to manage decorator instances  \n\n### 4. Code Style and Structure\n\n- Comply with TypeScript strict mode  \n- Utilize NestJS Exception classes (ForbiddenException, UnauthorizedException)  \n- Ensure type safety using typia tags  \n- Add appropriate JSDoc comments  \n\n## Reference Functions and Examples  \n\n### JWT Authentication Function  \n\n```typescript\n// File path: src/providers/authorize/jwtAuthorize.ts\nimport { ForbiddenException, UnauthorizedException } from "@nestjs/common";\nimport jwt from "jsonwebtoken";\n\nimport { MyGlobal } from "../../MyGlobal";\n\nexport function jwtAuthorize(props: {\n  request: {\n    headers: { authorization?: string };\n  };\n}) {\n  if (!props.request.headers.authorization)\n    throw new ForbiddenException("No token value exists");\n  else if (\n    props.request.headers.authorization.startsWith(BEARER_PREFIX) === false\n  )\n    throw new UnauthorizedException("Invalid token");\n\n  // PARSE TOKEN\n  try {\n    const token: string = props.request.headers.authorization.substring(\n      BEARER_PREFIX.length,\n    );\n\n    const verified = jwt.verify(token, MyGlobal.env.JWT_SECRET_KEY);\n\n    return verified;\n  } catch {\n    throw new UnauthorizedException("Invalid token");\n  }\n}\n\nconst BEARER_PREFIX = "Bearer ";\n```  \n\n### Provider Function Example  \n\n**⚠️ CRITICAL IMPORT PATHS:**\n- `jwtAuthorize` MUST be imported from `"./jwtAuthorize"` (same directory)\n- NOT `"../../providers/authorize/jwtAuthorize"` ❌\n- NOT `"../jwtAuthorize"` ❌\n- ONLY `"./jwtAuthorize"` ✅\n\n```typescript\n// File path: src/providers/authorize/adminAuthorize.ts\nimport { ForbiddenException } from "@nestjs/common";\n\nimport { MyGlobal } from "../../MyGlobal";\nimport { jwtAuthorize } from "./jwtAuthorize";  // ← CORRECT: Same directory import\nimport { AdminPayload } from "../../decorators/payload/AdminPayload";\n\nexport async function adminAuthorize(request: {\n  headers: {\n    authorization?: string;\n  };\n}): Promise<AdminPayload> {\n  const payload: AdminPayload = jwtAuthorize({ request }) as AdminPayload;\n\n  if (payload.type !== "admin") {\n    throw new ForbiddenException(`You\'re not ${payload.type}`);\n  }\n\n  const admin = await MyGlobal.prisma.admins.findFirst({\n    where: {\n      id: payload.id,\n      user: {\n        deleted_at: null,\n        is_banned: false,\n      },\n    },\n  });\n\n  if (admin === null) {\n    throw new ForbiddenException("You\'re not enrolled");\n  }\n\n  return payload;\n}\n```  \n\n### Decorator Example\n\n```typescript\n// File path: src/decorators/AdminAuth.ts\nimport { SwaggerCustomizer } from "@nestia/core";\nimport { ExecutionContext, createParamDecorator } from "@nestjs/common";\nimport { Singleton } from "tstl";\n\nimport { adminAuthorize } from "../providers/authorize/adminAuthorize";\n\nexport const AdminAuth =\n  (): ParameterDecorator =>\n  (\n    target: object,\n    propertyKey: string | symbol | undefined,\n    parameterIndex: number,\n  ): void => {\n    SwaggerCustomizer((props) => {\n      props.route.security ??= [];\n      props.route.security.push({\n        bearer: [],\n      });\n    })(target, propertyKey as string, undefined!);\n    singleton.get()(target, propertyKey, parameterIndex);\n  };\n\nconst singleton = new Singleton(() =>\n  createParamDecorator(async (_0: unknown, ctx: ExecutionContext) => {\n    const request = ctx.switchToHttp().getRequest();\n    return adminAuthorize(request);\n  })(),\n);\n```  \n\n### Decorator Type Example  \n\nIn case of the columns related to Date type like `created_at`, `updated_at`, `deleted_at`, must use the `string & tags.Format<\'date-time\'>` Type instead of Date type.  \n\n```typescript\n// File path: src/decorators/payload/AdminPayload.ts\nimport { tags } from "typia";\n\nexport interface AdminPayload {\n  /**\n   * Admin ID.\n   */\n  id: string & tags.Format<"uuid">;\n\n  /**\n   * Discriminator for the discriminated union type.\n   */\n  type: "admin";\n}\n```  \n\n## Output Format  \n\nYou must provide your response in a structured JSON format containing the following nested structure:  \n\n**provider**: An object containing the authentication Provider function configuration  \n\n- **name**: The name of the authentication Provider function in `{role}Authorize` format (e.g., adminAuthorize, userAuthorize). This function verifies JWT tokens and returns user information for the specified role.  \n- **code**: Complete TypeScript code for the authentication Provider function only. Must include JWT verification, role checking, database query logic, and proper import statements for the Payload interface.\n\n**decorator**: An object containing the authentication Decorator configuration  \n\n- **name**: The name of the Decorator to be generated in `{Role}Auth` format (e.g., AdminAuth, UserAuth). The decorator name used in Controller method parameters.  \n- **code**: Complete TypeScript code for the Decorator. Must include complete authentication decorator implementation using SwaggerCustomizer, createParamDecorator, and Singleton pattern.\n\n**decoratorType**: An object containing the Decorator Type configuration\n\n- **name**: The name of the Decorator Type in `{Role}Payload` format (e.g., AdminPayload, UserPayload). Used as the TypeScript type for the authenticated user data.\n- **code**: Complete TypeScript code for the Payload type interface. Must include proper field definitions with typia tags for type safety.\n\n## Work Process  \n\n1. Analyze the input Role name  \n2. Generate Provider function for the Role  \n3. Define Payload interface  \n4. Implement Decorator  \n5. Verify that all code follows example patterns  \n6. Generate response in specified format  \n\n## Quality Standards  \n\n- Ensure type safety  \n- Follow NestJS conventions  \n- Complete error handling  \n- Code reusability  \n- Complete documentation  \n\n## Common Mistakes to Avoid\n\n1. **❌ INCORRECT jwtAuthorize import paths:**\n   ```typescript\n   // WRONG - Do not use these:\n   import { jwtAuthorize } from "../../providers/authorize/jwtAuthorize";\n   import { jwtAuthorize } from "../authorize/jwtAuthorize";\n   import { jwtAuthorize } from "../../providers/jwtAuthorize";\n   ```\n\n2. **✅ CORRECT jwtAuthorize import path:**\n   ```typescript\n   // CORRECT - Always use this:\n   import { jwtAuthorize } from "./jwtAuthorize";\n   ```\n\nWhen users provide Role information, generate complete and practical authentication code according to the above rules.'
 }, {
     id: v4(),
     created_at: (new Date).toISOString(),
@@ -6955,7 +7299,7 @@ const claude$6 = {
             type: "object",
             properties: {
                 error_analysis: {
-                    description: "Step 1: TypeScript compilation error analysis and diagnosis.\n\nAI identifies all compilation errors (type mismatches, imports, syntax)\nand categorizes them by component (provider/decorator/payload). Analyzes\nerror dependencies and determines fix priorities for systematic\nresolution.",
+                    description: "Step 1: TypeScript compilation error analysis and diagnosis.\n\nAI identifies all compilation errors (type mismatches, imports, syntax)\nand categorizes them by component (providers/decorator/payload). Analyzes\nerror dependencies and determines fix priorities for systematic\nresolution.",
                     type: "string"
                 },
                 corrected_implementation: {
@@ -7145,7 +7489,7 @@ const collection$6 = {
                 type: "object",
                 properties: {
                     error_analysis: {
-                        description: "Step 1: TypeScript compilation error analysis and diagnosis.\n\nAI identifies all compilation errors (type mismatches, imports, syntax)\nand categorizes them by component (provider/decorator/payload). Analyzes\nerror dependencies and determines fix priorities for systematic\nresolution.",
+                        description: "Step 1: TypeScript compilation error analysis and diagnosis.\n\nAI identifies all compilation errors (type mismatches, imports, syntax)\nand categorizes them by component (providers/decorator/payload). Analyzes\nerror dependencies and determines fix priorities for systematic\nresolution.",
                         type: "string"
                     },
                     corrected_implementation: {
@@ -7326,7 +7670,7 @@ const transformRealizeAuthorizationHistories = (ctx, role) => [ {
     id: v4(),
     created_at: (new Date).toISOString(),
     type: "systemMessage",
-    text: '# NestJS Authentication Provider & Decorator Generation AI Agent  \n\nYou are a world-class NestJS expert and TypeScript developer. Your role is to automatically generate Provider functions and Decorators for JWT authentication based on given Role information and Prisma Schema.  \n\n## Core Mission  \n\nGenerate authentication Provider and Decorator code specialized for specific Roles based on Role information provided by users.  \n\n## Input Information  \n\n- **Role Name**: The authentication role to generate (e.g., admin, user, manager, etc.)  \n- **Prisma Schema**: Database table information.\n\n## Code Generation Rules  \n\n### 1. Provider Function Generation Rules  \n\n- Function name: `{role}Authorize` format (e.g., adminAuthorize, userAuthorize)  \n- Must use the `jwtAuthorize` function for JWT token verification  \n- Verify payload type and check if `payload.type` matches the correct role  \n- Query database using `MyGlobal.prisma.{tableName}` format to fetch **only the authorization model itself** - do not include relations or business logic models (no `include` statements for profile, etc.)  \n- Verify that the user actually exists in the database  \n- Function return type should be `{Role}Payload` interface  \n- Return the `payload` variable whenever feasible in provider functions.  \n- **Always check the Prisma schema for validation columns (e.g., `deleted_at`, status fields) within the authorization model and include them in the `where` clause to ensure the user is valid and active.**  \n\n### 2. Payload Interface Generation Rules  \n\n- Interface name: `{Role}Payload` format (e.g., AdminPayload, UserPayload)  \n- Required fields:  \n  - `id: string & tags.Format<"uuid">`: User ID (UUID format)  \n  - `type: "{role}"`: Discriminator for role identification  \n- Additional fields should be generated according to Role characteristics and "Prisma Schema"  \n\n### 3. Decorator Generation Rules  \n\n- Decorator name: `{Role}Auth` format (e.g., AdminAuth, UserAuth)  \n- Use SwaggerCustomizer to add bearer token security schema to API documentation  \n- Use createParamDecorator to implement actual authentication logic  \n- Use Singleton pattern to manage decorator instances  \n\n### 4. Code Style and Structure\n\n- Comply with TypeScript strict mode  \n- Utilize NestJS Exception classes (ForbiddenException, UnauthorizedException)  \n- Ensure type safety using typia tags  \n- Add appropriate JSDoc comments  \n\n## Reference Functions and Examples  \n\n### JWT Authentication Function  \n\n```typescript\nimport { ForbiddenException, UnauthorizedException } from "@nestjs/common";\nimport jwt from "jsonwebtoken";\n\nimport { MyGlobal } from "../MyGlobal";\n\nexport function jwtAuthorize(props: {\n  request: {\n    headers: { authorization?: string };\n  };\n}) {\n  if (!props.request.headers.authorization)\n    throw new ForbiddenException("No token value exists");\n  else if (\n    props.request.headers.authorization.startsWith(BEARER_PREFIX) === false\n  )\n    throw new UnauthorizedException("Invalid token");\n\n  // PARSE TOKEN\n  try {\n    const token: string = props.request.headers.authorization.substring(\n      BEARER_PREFIX.length,\n    );\n\n    const verified = jwt.verify(token, MyGlobal.env.JWT_SECRET_KEY);\n\n    return verified;\n  } catch {\n    throw new UnauthorizedException("Invalid token");\n  }\n}\n\nconst BEARER_PREFIX = "Bearer ";\n```  \n\n### Provider Function Example  \n\n```typescript\nimport { ForbiddenException } from "@nestjs/common";\n\nimport { MyGlobal } from "../../MyGlobal";\nimport { jwtAuthorize } from "./jwtAuthorize";\nimport { AdminPayload } from "../../decorators/payload/AdminPayload";\n\nexport async function adminAuthorize(request: {\n  headers: {\n    authorization?: string;\n  };\n}): Promise<AdminPayload> {\n  const payload: AdminPayload = jwtAuthorize({ request }) as AdminPayload;\n\n  if (payload.type !== "admin") {\n    throw new ForbiddenException(`You\'re not ${payload.type}`);\n  }\n\n  const admin = await MyGlobal.prisma.admins.findFirst({\n    where: {\n      id: payload.id,\n      user: {\n        deleted_at: null,\n        is_banned: false,\n      },\n    },\n  });\n\n  if (admin === null) {\n    throw new ForbiddenException("You\'re not enrolled");\n  }\n\n  return payload;\n}\n```  \n\n### Decorator Example\n\n```typescript\nimport { SwaggerCustomizer } from "@nestia/core";\nimport { ExecutionContext, createParamDecorator } from "@nestjs/common";\nimport { Singleton } from "tstl";\n\nimport { adminAuthorize } from "../providers/authorize/adminAuthorize";\n\nexport const AdminAuth =\n  (): ParameterDecorator =>\n  (\n    target: object,\n    propertyKey: string | symbol | undefined,\n    parameterIndex: number,\n  ): void => {\n    SwaggerCustomizer((props) => {\n      props.route.security ??= [];\n      props.route.security.push({\n        bearer: [],\n      });\n    })(target, propertyKey as string, undefined!);\n    singleton.get()(target, propertyKey, parameterIndex);\n  };\n\nconst singleton = new Singleton(() =>\n  createParamDecorator(async (_0: unknown, ctx: ExecutionContext) => {\n    const request = ctx.switchToHttp().getRequest();\n    return adminAuthorize(request);\n  })(),\n);\n```  \n\n### Decorator Type Example  \n\nIn case of the columns related to Date type like `created_at`, `updated_at`, `deleted_at`, must use the `string & tags.Format<\'date-time\'>` Type instead of Date type.  \n\n```typescript\nimport { tags } from "typia";\n\nexport interface AdminPayload {\n  /**\n   * Admin ID.\n   */\n  id: string & tags.Format<"uuid">;\n\n  /**\n   * Discriminator for the discriminated union type.\n   */\n  type: "admin";\n}\n```  \n\n## Output Format  \n\nYou must provide your response in a structured JSON format containing the following nested structure:  \n\n**provider**: An object containing the authentication Provider function configuration  \n\n- **name**: The name of the authentication Provider function in `{role}Authorize` format (e.g., adminAuthorize, userAuthorize). This function verifies JWT tokens and returns user information for the specified role.  \n- **code**: Complete TypeScript code for the authentication Provider function only. Must include JWT verification, role checking, database query logic, and proper import statements for the Payload interface.\n\n**decorator**: An object containing the authentication Decorator configuration  \n\n- **name**: The name of the Decorator to be generated in `{Role}Auth` format (e.g., AdminAuth, UserAuth). The decorator name used in Controller method parameters.  \n- **code**: Complete TypeScript code for the Decorator. Must include complete authentication decorator implementation using SwaggerCustomizer, createParamDecorator, and Singleton pattern.\n\n**decoratorType**: An object containing the Decorator Type configuration\n\n- **name**: The name of the Decorator Type in `{Role}Payload` format (e.g., AdminPayload, UserPayload). Used as the TypeScript type for the authenticated user data.\n- **code**: Complete TypeScript code for the Payload type interface. Must include proper field definitions with typia tags for type safety.\n\n## Work Process  \n\n1. Analyze the input Role name  \n2. Generate Provider function for the Role  \n3. Define Payload interface  \n4. Implement Decorator  \n5. Verify that all code follows example patterns  \n6. Generate response in specified format  \n\n## Quality Standards  \n\n- Ensure type safety  \n- Follow NestJS conventions  \n- Complete error handling  \n- Code reusability  \n- Complete documentation  \n\nWhen users provide Role information, generate complete and practical authentication code according to the above rules.'
+    text: '# NestJS Authentication Provider & Decorator Generation AI Agent  \n\nYou are a world-class NestJS expert and TypeScript developer. Your role is to automatically generate Provider functions and Decorators for JWT authentication based on given Role information and Prisma Schema.  \n\n## Core Mission  \n\nGenerate authentication Provider and Decorator code specialized for specific Roles based on Role information provided by users.  \n\n## Input Information  \n\n- **Role Name**: The authentication role to generate (e.g., admin, user, manager, etc.)  \n- **Prisma Schema**: Database table information.\n\n## File Structure\n\n**IMPORTANT: Understanding the file structure is crucial for correct import paths:**\n\n```\nsrc/\n├── MyGlobal.ts\n├── decorators/\n│   ├── AdminAuth.ts\n│   ├── UserAuth.ts\n│   └── payload/\n│       ├── AdminPayload.ts\n│       └── UserPayload.ts\n└── providers/\n    └── authorize/\n        ├── jwtAuthorize.ts      ← Shared JWT verification function\n        ├── adminAuthorize.ts    ← Same directory as jwtAuthorize\n        └── userAuthorize.ts     ← Same directory as jwtAuthorize\n```\n\n## Code Generation Rules  \n\n### 1. Provider Function Generation Rules  \n\n- Function name: `{role}Authorize` format (e.g., adminAuthorize, userAuthorize)  \n- Must use the `jwtAuthorize` function for JWT token verification  \n- **⚠️ CRITICAL: Import jwtAuthorize using `import { jwtAuthorize } from "./jwtAuthorize";` (NOT from "../../providers/authorize/jwtAuthorize" or any other path)**\n- Verify payload type and check if `payload.type` matches the correct role  \n- Query database using `MyGlobal.prisma.{tableName}` format to fetch **only the authorization model itself** - do not include relations or business logic models (no `include` statements for profile, etc.)  \n- Verify that the user actually exists in the database  \n- Function return type should be `{Role}Payload` interface  \n- Return the `payload` variable whenever feasible in provider functions.  \n- **Always check the Prisma schema for validation columns (e.g., `deleted_at`, status fields) within the authorization model and include them in the `where` clause to ensure the user is valid and active.**  \n\n### 2. Payload Interface Generation Rules  \n\n- Interface name: `{Role}Payload` format (e.g., AdminPayload, UserPayload)  \n- Required fields:  \n  - `id: string & tags.Format<"uuid">`: User ID (UUID format)  \n  - `type: "{role}"`: Discriminator for role identification  \n- Additional fields should be generated according to Role characteristics and "Prisma Schema"  \n\n### 3. Decorator Generation Rules  \n\n- Decorator name: `{Role}Auth` format (e.g., AdminAuth, UserAuth)  \n- Use SwaggerCustomizer to add bearer token security schema to API documentation  \n- Use createParamDecorator to implement actual authentication logic  \n- Use Singleton pattern to manage decorator instances  \n\n### 4. Code Style and Structure\n\n- Comply with TypeScript strict mode  \n- Utilize NestJS Exception classes (ForbiddenException, UnauthorizedException)  \n- Ensure type safety using typia tags  \n- Add appropriate JSDoc comments  \n\n## Reference Functions and Examples  \n\n### JWT Authentication Function  \n\n```typescript\n// File path: src/providers/authorize/jwtAuthorize.ts\nimport { ForbiddenException, UnauthorizedException } from "@nestjs/common";\nimport jwt from "jsonwebtoken";\n\nimport { MyGlobal } from "../../MyGlobal";\n\nexport function jwtAuthorize(props: {\n  request: {\n    headers: { authorization?: string };\n  };\n}) {\n  if (!props.request.headers.authorization)\n    throw new ForbiddenException("No token value exists");\n  else if (\n    props.request.headers.authorization.startsWith(BEARER_PREFIX) === false\n  )\n    throw new UnauthorizedException("Invalid token");\n\n  // PARSE TOKEN\n  try {\n    const token: string = props.request.headers.authorization.substring(\n      BEARER_PREFIX.length,\n    );\n\n    const verified = jwt.verify(token, MyGlobal.env.JWT_SECRET_KEY);\n\n    return verified;\n  } catch {\n    throw new UnauthorizedException("Invalid token");\n  }\n}\n\nconst BEARER_PREFIX = "Bearer ";\n```  \n\n### Provider Function Example  \n\n**⚠️ CRITICAL IMPORT PATHS:**\n- `jwtAuthorize` MUST be imported from `"./jwtAuthorize"` (same directory)\n- NOT `"../../providers/authorize/jwtAuthorize"` ❌\n- NOT `"../jwtAuthorize"` ❌\n- ONLY `"./jwtAuthorize"` ✅\n\n```typescript\n// File path: src/providers/authorize/adminAuthorize.ts\nimport { ForbiddenException } from "@nestjs/common";\n\nimport { MyGlobal } from "../../MyGlobal";\nimport { jwtAuthorize } from "./jwtAuthorize";  // ← CORRECT: Same directory import\nimport { AdminPayload } from "../../decorators/payload/AdminPayload";\n\nexport async function adminAuthorize(request: {\n  headers: {\n    authorization?: string;\n  };\n}): Promise<AdminPayload> {\n  const payload: AdminPayload = jwtAuthorize({ request }) as AdminPayload;\n\n  if (payload.type !== "admin") {\n    throw new ForbiddenException(`You\'re not ${payload.type}`);\n  }\n\n  const admin = await MyGlobal.prisma.admins.findFirst({\n    where: {\n      id: payload.id,\n      user: {\n        deleted_at: null,\n        is_banned: false,\n      },\n    },\n  });\n\n  if (admin === null) {\n    throw new ForbiddenException("You\'re not enrolled");\n  }\n\n  return payload;\n}\n```  \n\n### Decorator Example\n\n```typescript\n// File path: src/decorators/AdminAuth.ts\nimport { SwaggerCustomizer } from "@nestia/core";\nimport { ExecutionContext, createParamDecorator } from "@nestjs/common";\nimport { Singleton } from "tstl";\n\nimport { adminAuthorize } from "../providers/authorize/adminAuthorize";\n\nexport const AdminAuth =\n  (): ParameterDecorator =>\n  (\n    target: object,\n    propertyKey: string | symbol | undefined,\n    parameterIndex: number,\n  ): void => {\n    SwaggerCustomizer((props) => {\n      props.route.security ??= [];\n      props.route.security.push({\n        bearer: [],\n      });\n    })(target, propertyKey as string, undefined!);\n    singleton.get()(target, propertyKey, parameterIndex);\n  };\n\nconst singleton = new Singleton(() =>\n  createParamDecorator(async (_0: unknown, ctx: ExecutionContext) => {\n    const request = ctx.switchToHttp().getRequest();\n    return adminAuthorize(request);\n  })(),\n);\n```  \n\n### Decorator Type Example  \n\nIn case of the columns related to Date type like `created_at`, `updated_at`, `deleted_at`, must use the `string & tags.Format<\'date-time\'>` Type instead of Date type.  \n\n```typescript\n// File path: src/decorators/payload/AdminPayload.ts\nimport { tags } from "typia";\n\nexport interface AdminPayload {\n  /**\n   * Admin ID.\n   */\n  id: string & tags.Format<"uuid">;\n\n  /**\n   * Discriminator for the discriminated union type.\n   */\n  type: "admin";\n}\n```  \n\n## Output Format  \n\nYou must provide your response in a structured JSON format containing the following nested structure:  \n\n**provider**: An object containing the authentication Provider function configuration  \n\n- **name**: The name of the authentication Provider function in `{role}Authorize` format (e.g., adminAuthorize, userAuthorize). This function verifies JWT tokens and returns user information for the specified role.  \n- **code**: Complete TypeScript code for the authentication Provider function only. Must include JWT verification, role checking, database query logic, and proper import statements for the Payload interface.\n\n**decorator**: An object containing the authentication Decorator configuration  \n\n- **name**: The name of the Decorator to be generated in `{Role}Auth` format (e.g., AdminAuth, UserAuth). The decorator name used in Controller method parameters.  \n- **code**: Complete TypeScript code for the Decorator. Must include complete authentication decorator implementation using SwaggerCustomizer, createParamDecorator, and Singleton pattern.\n\n**decoratorType**: An object containing the Decorator Type configuration\n\n- **name**: The name of the Decorator Type in `{Role}Payload` format (e.g., AdminPayload, UserPayload). Used as the TypeScript type for the authenticated user data.\n- **code**: Complete TypeScript code for the Payload type interface. Must include proper field definitions with typia tags for type safety.\n\n## Work Process  \n\n1. Analyze the input Role name  \n2. Generate Provider function for the Role  \n3. Define Payload interface  \n4. Implement Decorator  \n5. Verify that all code follows example patterns  \n6. Generate response in specified format  \n\n## Quality Standards  \n\n- Ensure type safety  \n- Follow NestJS conventions  \n- Complete error handling  \n- Code reusability  \n- Complete documentation  \n\n## Common Mistakes to Avoid\n\n1. **❌ INCORRECT jwtAuthorize import paths:**\n   ```typescript\n   // WRONG - Do not use these:\n   import { jwtAuthorize } from "../../providers/authorize/jwtAuthorize";\n   import { jwtAuthorize } from "../authorize/jwtAuthorize";\n   import { jwtAuthorize } from "../../providers/jwtAuthorize";\n   ```\n\n2. **✅ CORRECT jwtAuthorize import path:**\n   ```typescript\n   // CORRECT - Always use this:\n   import { jwtAuthorize } from "./jwtAuthorize";\n   ```\n\nWhen users provide Role information, generate complete and practical authentication code according to the above rules.'
 }, {
     id: v4(),
     created_at: (new Date).toISOString(),
@@ -7334,20 +7678,25 @@ const transformRealizeAuthorizationHistories = (ctx, role) => [ {
     text: [ "## Role", "", role, "", "## Prisma Schema", "", JSON.stringify(ctx.state().prisma?.schemas, null, 2), "", "## File Structure Example", "", "Please refer to the following file structure to construct appropriate import paths:", "", "File locations:", "", `- Decorator Path : ${AuthorizationFileSystem.decoratorPath("AdminAuth.ts")}`, `- Payload Path : ${AuthorizationFileSystem.payloadPath("AdminPayload.ts")}`, `- Provider Path : ${AuthorizationFileSystem.providerPath("adminAuthorize.ts")}`, "" ].join("\n")
 } ];
 
+var InternalFileSystem;
+
+(function(InternalFileSystem) {
+    InternalFileSystem.DEFAULT = [ "src/providers/authorize/jwtAuthorize.ts", "src/MyGlobal.ts", "src/util/toISOStringSafe.ts" ];
+})(InternalFileSystem || (InternalFileSystem = {}));
+
 async function orchestrateRealizeAuthorization(ctx) {
     const roles = ctx.state().interface?.document.components.authorization?.map((auth => auth.name)) ?? [];
     let completed = 0;
-    const templateFiles = {
-        "src/MyGlobal.ts": await fs.readFile(path.join(__dirname, "../../../../../internals/template/realize/src/MyGlobal.ts"), "utf-8"),
-        [AuthorizationFileSystem.providerPath("jwtAuthorize")]: await fs.readFile(path.join(__dirname, "../../../../../internals/template/realize/src/providers/jwtAuthorize.ts"), "utf-8")
-    };
+    const templateFiles = await (await ctx.compiler()).realize.getTemplate();
     ctx.dispatch({
         type: "realizeAuthorizationStart",
         step: ctx.state().test?.step ?? 0,
         created_at: (new Date).toISOString()
     });
     const authorizations = await Promise.all(roles.map((async role => {
-        const authorization = await process$2(ctx, role, templateFiles);
+        const authorization = await process$2(ctx, role, InternalFileSystem.DEFAULT.map((el => ({
+            [el]: templateFiles[el]
+        }))).reduce(((acc, cur) => Object.assign(acc, cur)), {}));
         ctx.dispatch({
             type: "realizeAuthorizationWrite",
             created_at: (new Date).toISOString(),
@@ -7838,6 +8187,20 @@ const collection$5 = {
     3.1: claude$5
 };
 
+function arrayToRecord(items, keyProp, valueProp) {
+    if (items.length > 0 && Array.isArray(items[0]) && items[0].length === 2) {
+        return items.reduce(((acc, [key, value]) => Object.assign(acc, {
+            [key]: value
+        })), {});
+    }
+    if (keyProp !== undefined && valueProp !== undefined) {
+        return items.map((item => ({
+            [String(item[keyProp])]: item[valueProp]
+        }))).reduce(((acc, cur) => Object.assign(acc, cur)), {});
+    }
+    throw new Error("Invalid arguments for arrayToRecord");
+}
+
 const FAILED = Symbol("FAILED");
 
 function pipe(a, ...fns) {
@@ -7847,6 +8210,63 @@ function pipe(a, ...fns) {
     }))), Promise.resolve(a));
 }
 
+async function randomBackoffRetry(fn, options = {}) {
+    const {maxRetries = 5, baseDelay = 4e3, maxDelay = 6e4, jitter = .8, handleError = isRetryError} = options;
+    let lastError;
+    for (let attempt = 0; attempt < maxRetries; attempt++) {
+        try {
+            return await fn();
+        } catch (err) {
+            lastError = err;
+            if (attempt === maxRetries - 1) throw err;
+            if (!handleError(err)) throw err;
+            const tempDelay = Math.min(baseDelay * 2 ** attempt, maxDelay);
+            const delay = tempDelay * (1 + Math.random() * jitter);
+            await new Promise((res => setTimeout(res, delay)));
+        }
+    }
+    throw lastError;
+}
+
+function randomBackoffStrategy(props) {
+    const {count, error} = props;
+    if (count > 5) {
+        throw error;
+    }
+    if (isRetryError(error) === false) {
+        throw error;
+    }
+    const baseDelay = 4e3;
+    const maxDelay = 6e4;
+    const jitter = .8;
+    const tempDelay = Math.min(baseDelay * 2 ** count, maxDelay);
+    const delay = tempDelay * (1 + Math.random() * jitter);
+    return delay;
+}
+
+function isRetryError(error) {
+    if (error?.code === "insufficient_quota" || error?.error?.type === "insufficient_quota") {
+        return false;
+    }
+    if (typeof error?.status === "number" && error.status >= 500 || error?.error?.type === "server_error") {
+        return true;
+    }
+    if (error?.status === 429) {
+        return true;
+    }
+    const code = error?.code || error?.cause?.code;
+    if ([ "UND_ERR_SOCKET", "UND_ERR_CONNECT_TIMEOUT", "ETIMEDOUT", "ECONNRESET", "EPIPE" ].includes(code)) {
+        return true;
+    }
+    if (error?.message === "terminated" || error?.name === "AbortError") {
+        return true;
+    }
+    if (error?.message?.startsWith(`SyntaxError: Expected ',' or '}' after property value in JSON at position`)) {
+        return true;
+    }
+    return false;
+}
+
 async function getTestScenarioArtifacts(ctx, scenario) {
     const compiler = await ctx.compiler();
     const document = filterDocument(scenario, ctx.state().interface.document);
@@ -7866,6 +8286,7 @@ async function getTestScenarioArtifacts(ctx, scenario) {
 function filterDocument(scenario, document) {
     const operations = document.operations.filter((op => scenario.endpoint.method === op.method && scenario.endpoint.path === op.path || scenario.dependencies.some((dp => dp.endpoint.method === op.method && dp.endpoint.path === op.path))));
     const components = {
+        authorization: document.components.authorization,
         schemas: {}
     };
     const visit = typeName => {
@@ -7923,12 +8344,12 @@ const transformRealizeCoderHistories = (state, props, artifacts, previous, diagn
         id: v4(),
         created_at: (new Date).toISOString(),
         type: "systemMessage",
-        text: "# 🧠 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\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   - ✅ REQUIRED: Define all parameters inline:\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 Object.prototype.hasOwnProperty.call() for field checks**\n   - ❌ ABSOLUTELY FORBIDDEN: `Object.prototype.hasOwnProperty.call(body, \"field\")`\n   - ❌ ALSO FORBIDDEN: `body.hasOwnProperty(\"field\")`\n   - ✅ REQUIRED: Use simple patterns:\n     ```typescript\n     // For updates - simple nullish coalescing\n     field: body.field ?? undefined\n     \n     // For explicit null handling\n     field: body.field === null ? null : (body.field ?? undefined)\n     \n     // For conditional inclusion\n     ...(body.field !== undefined && { field: body.field })\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 authenticated user parameter exists**\n   - **CRITICAL RULE**: If the function receives an authenticated user (not `Record<string, never>`), it MUST use that user 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 authenticated user parameter\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 `RealizeCoderOutput` 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 interface RealizeCoderOutput {\n  plan: string;\n  prisma_schemas: string;\n  draft_without_date_type: string;\n  review: string;\n  withCompilerFeedback?: string;\n  implementationCode: string;\n}\n```\n\n### Field Descriptions\n\n* **plan**:\n  A high-level explanation of how the task will be approached. This should outline the logic and strategy *before* any code is written.\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  \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\n* **draft\\_without\\_date\\_type**:\n  A rough version of the code with special care to **never use the `Date` type**. Use `string & tags.Format<'date-time'>` or other string-based formats instead. This stage exists to validate that the type model follows the team's conventions, especially around temporal data.\n  \n  **MUST** use only fields verified to exist in the schema during the plan phase.\n\n* **review**:\n  A self-review of the draft code. This should include commentary on correctness, potential issues, or why certain trade-offs were made.\n  \n  **Should validate**: Field usage against schema, type safety, and adherence to conventions.\n\n* **withCompilerFeedback?** (optional):\n  If the draft caused TypeScript errors or warnings, include a corrected version of the code here with fixes and a brief explanation of what was changed.\n  \n  **Common fixes**: Field existence errors, type mismatches, nullable field handling.\n\n* **implementationCode**:\n  The final, production-ready implementation. This version should reflect all improvements and pass type checks, ideally without needing further revision.\n  \n  **Must guarantee**: All referenced fields exist in the schema, proper type handling, and error-free compilation.\n\n### Schema-First Planning Example\n\n```\nplan: \"\nSTEP 1 - PRISMA SCHEMA VERIFICATION:\nChecked REALIZE_CODER_ARTIFACT.md for discussionboard_user model schema:\nmodel discussionboard_user {\n  id            String   @id\n  email         String   @unique\n  password_hash String\n  display_name  String?\n  avatar_url    String?\n  is_active     Boolean  @default(true)\n  is_banned     Boolean  @default(false)\n  created_at    DateTime @default(now())\n  updated_at    DateTime @updatedAt\n}\n\nCRITICAL: Common fields that DO NOT EXIST in this model:\n- deleted_at (NO SOFT DELETE SUPPORT - will use hard delete)\n- created_by (no audit trail)\n- updated_by (no audit trail)\n- is_deleted (no soft delete flag)\n\nSTEP 2 - API SPEC VS SCHEMA VERIFICATION:\nAPI Comment requires: Soft delete with deleted_at field\nPrisma Schema has: No deleted_at field\nCONTRADICTION DETECTED: API specification requires soft delete but schema doesn't support it\n\nSTEP 3 - FIELD INVENTORY:\nConfirmed fields available for use:\n- id, email, password_hash, display_name, avatar_url\n- is_active, is_banned (Boolean flags)\n- created_at, updated_at (DateTime fields)\n\nSTEP 4 - FIELD ACCESS STRATEGY:\n- Select: Will only select fields that exist: id, email, is_active, created_at\n- Update: Can update is_active, is_banned, display_name, avatar_url\n- Delete: Must use hard delete since no deleted_at field exists\n\nSTEP 5 - TYPE COMPATIBILITY:\n- DateTime fields (created_at, updated_at): Convert using toISOStringSafe()\n- Optional fields (display_name, avatar_url): Handle null values properly\n- Use IDiscussionboardUser from ../api/structures for type safety\n\nSTEP 6 - IMPLEMENTATION DECISION:\nDue to API-Schema contradiction, will implement placeholder with typia.random<T>()\nCannot fulfill API requirements without schema modification\n\nSTEP 7 - RETURN TYPE STRATEGY:\nFunction return type is Promise<IDiscussionboardUser>\nWill NOT use satisfies on return statement - redundant with function signature\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\nThe function must always take the following **three arguments**:\n\n**Without authentication** (no decoratorEvent):\n```typescript\nexport async function something(\n  user: Record<string, never>,  // No authentication required\n  parameters: Record<string, string>,\n  body: Record<string, any>\n) {\n  ...\n}\n```\n\n**With authentication** (decoratorEvent provided):\n\n```typescript\n// Import the specific type from decoratorEvent\nimport { AdminPayload } from '../authentications/types/AdminPayload';\n\nexport async function delete__users_$id(\n  admin: AdminPayload,  // Specific type instead of generic user\n  parameters: Record<string, string>,\n  body: Record<string, any>\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: parameters.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\nThis structure must be used even for GET requests or when `parameters` or `body` are unused.\nIn such cases, define them as:\n\n```typescript\nparameters: Record<string, never>\nbody: Record<string, never>\n```\n\n> ⚠️ Do not omit any of the three arguments. All functions must include user, parameters, and body, even if some of them are unused. This ensures consistent structure and prevents runtime or compilation errors due to missing parameters.\n\n> ⚠️ When throwing errors, please use Error objects and do not use any other error formats.\n\n> 🔐 **CRITICAL User Parameter Rules**:\n> - **NO decoratorEvent**: Use `user: Record<string, never>` (empty object type)\n> - **WITH decoratorEvent**: Use the specific type from decoratorEvent (e.g., `admin: AdminPayload`)\n> - **NEVER use** `user: { id: string & tags.Format<'uuid'>, type: string }` - this is an outdated pattern\n> - The parameter name should match the role (e.g., `admin` for AdminPayload, `user` for UserPayload)\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 types or `Record<string, never>`\n3. 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     - `typia.assert<T>()` for runtime validation and type conversion\n     - `typia.assertGuard<T>()` for type narrowing with validation\n     - Custom type guards for complex validation logic\n\n    > ⚠️ Only use `as` when you can guarantee type safety. When in doubt, prefer validation over assertion.\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 `../api/structures` can be imported and used indefinitely as an exception. prioritize the use of the type defined here over the type of Prisma.\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 such as:\n   > `\"Property 'assert' does not exist on type 'typeof import(\\\"node_modules/typia/lib/tags/index\\\")'\"`\n   > \n   > **Note**: Use auto-injected modules directly (e.g., `typia.assert()`, `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. **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, mode: \"insensitive\" as const },\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\nThe following modules are **automatically injected** at the top of every generated file:\n\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- **When decoratorEvent is provided**: `import { ${decoratorType} } from \"../authentications/types/${decoratorType}\";`\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 validated = typia.assert<IUser>(data);\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 prefer using types defined in `../api/structures` or your own explicitly implemented types when possible.\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  - Types in `../api/structures` are designed to be schema-agnostic and stable\n\n- **Mandatory Alternative: Use ../api/structures Types**  \n  Always use the interface types defined in `../api/structures` directory instead:\n\n  ```typescript\n  // ✅ CORRECT: Use stable, schema-agnostic types\n  import { IDiscussionboardModerator } from \"../api/structures/IDiscussionboardModerator\";\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  // ✅ Import from ../api/structures\n  import { IModelName } from \"../api/structures/IModelName\";\n  \n  // ✅ Use the appropriate nested interface\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**❌ 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 api/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 `user` parameter is NOT `Record<string, never>`, then EVERY operation MUST have authorization logic:\n\n### Delete Operations - OWNERSHIP IS MANDATORY\n```typescript\nexport async function delete__posts_$id(\n  user: UserPayload,  // 🔴 User parameter exists = MUST check authorization\n  parameters: { id: string & tags.Format<'uuid'> },\n  body: Record<string, never>\n) {\n  // 🔴 STEP 1: ALWAYS fetch the resource FIRST\n  const post = await MyGlobal.prisma.posts.findUniqueOrThrow({\n    where: { id: parameters.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: parameters.id },\n    data: { deleted_at: toISOStringSafe(new Date()) }\n  });\n}\n\n// ❌ WRONG - Missing authorization check\nexport async function delete__posts_$id_WRONG(\n  user: UserPayload,  // User exists but NOT USED - THIS IS FORBIDDEN\n  parameters: { id: string & tags.Format<'uuid'> },\n  body: Record<string, never>\n) {\n  // ❌ FORBIDDEN: Directly deleting without checking ownership\n  await MyGlobal.prisma.posts.update({\n    where: { id: parameters.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  user: UserPayload,\n  parameters: { id: string & tags.Format<'uuid'> },\n  body: IBoardUpdateInput\n) {\n  const board = await MyGlobal.prisma.boards.findUniqueOrThrow({\n    where: { id: parameters.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  user: UserPayload,\n  parameters: { boardId: string & tags.Format<'uuid'> },\n  body: IPostCreateInput\n) {\n  // Check if user has access to the board\n  const membership = await MyGlobal.prisma.board_members.findFirst({\n    where: {\n      board_id: parameters.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: parameters.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: parameters.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  user: Record<string, never>,  // Or specific type if authentication required\n  parameters: { id: string & tags.Format<\"uuid\"> },\n  body: Record<string, never>\n): Promise<void> {\n  // Cannot implement due to API-Schema contradiction\n  return typia.random<void>();\n}\n```\n\n### Key Rules for Contradictions:\n\n- **NEVER attempt to use fields that don't exist** in the Prisma schema\n- **NEVER ignore API specifications** - document why they can't be followed\n- **ALWAYS return `typia.random<T>()`** with comprehensive documentation\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* Never use `MyGlobal.logs.create(...)` directly — always go through `MyGlobal.prisma`.\n\n---\n\n## 📚 Prisma Usage Guide\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 types defined under `../api/structures`, 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* Receive `user`, `parameters`, and `body` from the controller\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 API structure types from `../api/structures`\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 `typia.assertGuard` or `typia.assert`:\n\n```ts\nvoid typia.assertGuard<1 | -1>(body.value);\nvalue // 1 | -1\n```\n\n```ts\nconst value = typia.assert<1 | -1>(body.value); // 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❌ **Issue with simple boolean checks**:\n```ts\nconst hasPostId = body.post_id !== undefined && body.post_id !== null;\nif (hasPostId) {\n  // TypeScript still thinks body.post_id could be null!\n  await prisma.findFirst({ where: { id: body.post_id } }); // Type error\n}\n```\n\n✅ **Fix Options**:\n\n1. **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 either a validated cast or `typia.assertGuard`:\n\n```ts\nconst id = body.id as string & tags.Format<'uuid'>; // Allowed exception\n```\n\nOR:\n\n```ts\nconst id = typia.assertGuard<string & tags.Format<'uuid'>>(body.id);\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 `../api/structures` 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 `../api/structures` 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 ../api/structures types for field validation\nimport { IModel } from \"../api/structures/IModel\";\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 ../api/structures types for update operations\n\n**DO:**\n\n```ts\nimport { IUserRoles } from \"../api/structures/IUserRoles\";\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 ../api/structures types, never Prisma generated types\n\nAPI structure types from `../api/structures` 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\nimport { IUserRoles } from \"../api/structures/IUserRoles\";\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\nimport { IUserRoles } from \"../api/structures/IUserRoles\";\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, mode: \"insensitive\" as const }\n    }),\n    ...(description && description.length > 0 && { \n      description: { contains: description, mode: \"insensitive\" as const }\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 `../api/structures` types only            |\n| Assign `null` to non-nullable fields       | Use `?? undefined` or omit                     |\n| Use Prisma types for update operations     | Use `IModel.IUpdate` from api/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 `../api/structures` 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 `../api/structures` 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 api/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### 🔧 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        mode: \"insensitive\" as const,\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# 🔐 Browser-Compatible Native-First Rule\n\nYou must implement all functionality using **only browser-compatible native features** whenever possible.  \nAll logic must assume it will run in a browser environment — even if Node.js is also supported.\n\n> 🚫 Do **not** use Node.js-only modules like `'crypto'`, `'fs'`, `'path'`, etc.\n> ✅ Always use **Web-standard, browser-safe APIs**.\n\n---\n\n## ✅ Encryption Rule\n\nAll encryption and decryption must be implemented using the **Web Crypto API (`window.crypto.subtle`)**.\n\n**❌ Do not use:**\n- `crypto` (Node.js built-in)\n- `crypto-js`, `bcrypt`, `libsodium`, or any other third-party crypto libraries\n\n**✅ Only use:**\n- `window.crypto.subtle` and `window.crypto.getRandomValues`\n\n```ts\n// Example: AES-GCM encryption in the browser\nconst key = await crypto.subtle.generateKey(\n  { name: 'AES-GCM', length: 256 },\n  true,\n  ['encrypt', 'decrypt']\n);\n\nconst iv = crypto.getRandomValues(new Uint8Array(12));\n\nconst encoded = new TextEncoder().encode('hello world');\nconst encrypted = await crypto.subtle.encrypt(\n  { name: 'AES-GCM', iv },\n  key,\n  encoded\n);\n````\n\n---\n\n## ✅ General API Rule\n\nYou must avoid Node.js-specific or third-party libraries. All implementations must be fully functional in **browser environments**, using **web-standard APIs** only.\n\n| Use Case        | ❌ Do Not Use (Node.js / External)                 | ✅ Use Instead (Browser-safe)               |\n| --------------- | ------------------------------------------------- | ------------------------------------------ |\n| UUID Generation | `uuid` package, `crypto.randomUUID()` (Node only) | `crypto.randomUUID()` (browser supported)  |\n| HTTP Requests   | `axios`, `node-fetch`                             | `fetch`                                    |\n| Timing / Delay  | `sleep-promise`, `delay`                          | `setTimeout`, `await new Promise(...)`     |\n| Hashing         | `crypto.createHash()` (Node.js)                   | `crypto.subtle.digest()`                   |\n| Compression     | `zlib`, `adm-zip`, `archiver`                     | `CompressionStream`, `DecompressionStream` |\n| File Handling   | `fs`, `fs-extra`                                  | `File`, `Blob`, `FileReader`, `Streams`    |\n\n---\n\n## 🧷 Summary\n\n* ✅ Use only APIs that work natively in **browsers**.\n* 🚫 Do not use Node.js-only modules or platform-specific packages.\n* ❌ Avoid third-party libraries unless there's **no equivalent** browser-native solution.\n* 🧭 If your logic must run both in Node.js and the browser, **the browser must always be the lowest common denominator**—ensure everything works in the browser first.\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## 🔧 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## 🎯 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## 🛡️ `typia.assert` vs `typia.assertGuard`\n\n`typia` provides two main runtime validation utilities: `assert` and `assertGuard`.\nBoth serve to validate runtime data against a TypeScript type, but their **behavior and return types differ**, which can influence which one to use depending on your use case.\n\n### 🔍 `typia.assert<T>(input): T`\n\n* Validates that `input` conforms to type `T`.\n* If invalid, throws a detailed exception.\n* **Returns** the parsed and validated input as type `T`.\n* Ideal when you want **to validate and use the result immediately**.\n\n**Example:**\n\n```ts\nconst user = typia.assert<IUser>(input); // user is of type IUser\n```\n\n---\n\n### 🧪 `typia.assertGuard<T>(input): void`\n\n* Validates that `input` conforms to type `T`.\n* If invalid, throws an exception like `assert`.\n* **Does not return anything** (`void` return type).\n* Acts like a **type guard** for the input **within the scope**.\n* Useful when you want to narrow the type **for subsequent logic**, but **don't need to reassign the value**.\n\n**Example:**\n\n```ts\ntypia.assertGuard<IUser>(input); // input is now treated as IUser\n\n// input can be used safely as IUser here\nconsole.log(input.username);\n```\n\n### 📎 Appendix – `assert` vs `assertGuard`\n\n```ts\n/**\n * Asserts a value type.\n *\n * Asserts a parametric value type and throws a {@link TypeGuardError} with detailed\n * reason, if the parametric value is not following the type `T`. Otherwise, the\n * value is following the type `T`, just input parameter would be returned.\n *\n * If what you want is not asserting but just knowing whether the parametric value is\n * following the type `T` or not, you can choose the {@link is} function instead.\n * Otherwise you want to know all the errors, {@link validate} is the way to go.\n * Also, if you want to automatically cast the parametric value to the type `T`\n * when no problem (perform the assertion guard of type).\n *\n * On the other and, if you don't want to allow any superfluous property that is not\n * enrolled to the type `T`, you can use {@link assertEquals} function instead.\n *\n * @template T Type of the input value\n * @param input A value to be asserted\n * @param errorFactory Custom error factory. Default is `TypeGuardError`\n * @returns Parametric input value\n * @throws A {@link TypeGuardError} instance with detailed reason\n *\n * @author Jeongho Nam - https://github.com/samchon\n */\nexport declare function assert<T>(input: T, errorFactory?: undefined | ((props: TypeGuardError.IProps) => Error)): T;\n/**\n * Asserts a value type.\n *\n * Asserts a parametric value type and throws a {@link TypeGuardError} with detailed\n * reason, if the parametric value is not following the type `T`. Otherwise, the\n * value is following the type `T`, just input parameter would be returned.\n *\n * If what you want is not asserting but just knowing whether the parametric value is\n * following the type `T` or not, you can choose the {@link is} function instead.\n * Otherwise, you want to know all the errors, {@link validate} is the way to go.\n *\n * On the other and, if you don't want to allow any superfluous property that is not\n * enrolled to the type `T`, you can use {@link assertEquals} function instead.\n *\n * @template T Type of the input value\n * @param input A value to be asserted\n * @param errorFactory Custom error factory. Default is `TypeGuardError`\n * @returns Parametric input value casted as `T`\n * @throws A {@link TypeGuardError} instance with detailed reason\n *\n * @author Jeongho Nam - https://github.com/samchon\n */\nexport declare function assert<T>(input: unknown, errorFactory?: undefined | ((props: TypeGuardError.IProps) => Error)): T;\n/**\n * Assertion guard of a value type.\n *\n * Asserts a parametric value type and throws a {@link TypeGuardError} with detailed\n * reason, if the parametric value is not following the type `T`. Otherwise, the\n * value is following the type `T`, nothing would be returned, but the input value\n * would be automatically casted to the type `T`. This is the concept of\n * \"Assertion Guard\" of a value type.\n *\n * If what you want is not asserting but just knowing whether the parametric value is\n * following the type `T` or not, you can choose the {@link is} function instead.\n * Otherwise you want to know all the errors, {@link validate} is the way to go.\n * Also, if you want to returns the parametric value when no problem, you can use\n * {@link assert} function instead.\n *\n * On the other and, if you don't want to allow any superfluous property that is not\n * enrolled to the type `T`, you can use {@link assertGuardEquals} function instead.\n *\n * @template T Type of the input value\n * @param input A value to be asserted\n * @param errorFactory Custom error factory. Default is `TypeGuardError`\n * @throws A {@link TypeGuardError} instance with detailed reason\n *\n * @author Jeongho Nam - https://github.com/samchon\n */\nexport declare function assertGuard<T>(input: T, errorFactory?: undefined | ((props: TypeGuardError.IProps) => Error)): asserts input is T;\n/**\n * Assertion guard of a value type.\n *\n * Asserts a parametric value type and throws a {@link TypeGuardError} with detailed\n * reason, if the parametric value is not following the type `T`. Otherwise, the\n * value is following the type `T`, nothing would be returned, but the input value\n * would be automatically casted to the type `T`. This is the concept of\n * \"Assertion Guard\" of a value type.\n *\n * If what you want is not asserting but just knowing whether the parametric value is\n * following the type `T` or not, you can choose the {@link is} function instead.\n * Otherwise you want to know all the errors, {@link validate} is the way to go.\n * Also, if you want to returns the parametric value when no problem, you can use\n * {@link assert} function instead.\n *\n * On the other and, if you don't want to allow any superfluous property that is not\n * enrolled to the type `T`, you can use {@link assertGuardEquals} function instead.\n *\n * @template T Type of the input value\n * @param input A value to be asserted\n * @param errorFactory Custom error factory. Default is `TypeGuardError`\n * @throws A {@link TypeGuardError} instance with detailed reason\n *\n * @author Jeongho Nam - https://github.com/samchon\n */\nexport declare function assertGuard<T>(input: unknown, errorFactory?: undefined | ((props: TypeGuardError.IProps) => Error)): asserts input is T;\n\n```\n\n### Handling Typia Assertion 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 **typia.assert** to explicitly assert or validate the value conforms to the expected `uint32` format.\n- Example:\n\n```ts\nconst value = getValue(); // type: number & tags.Type<\"int32\">\n\ntypia.assert<number & tags.Type<\"int32\"> & tags.JsonSchemaPlugin<{ format: \"uint32\" }>>(value);\n\n// Now `value` is guaranteed to conform to the expected unsigned 32-bit integer type.\n```\n\n* Always use typia.tags' `assert` or related functions for runtime validation and to satisfy TypeScript's type checker.\n* This approach ensures type safety without compromising runtime correctness.\n\n---\n\n### ✅ Summary: Which Should I Use?\n\n| Use Case                             | Recommended API          |\n| ------------------------------------ | ------------------------ |\n| Validate and return typed value      | `typia.assert<T>()`      |\n| Narrow type without reassigning      | `typia.assertGuard<T>()` |\n| Use validated object directly        | `typia.assert<T>()`      |\n| Use input inside a conditional block | `typia.assertGuard<T>()` |\n\n> **Note:** Since `assertGuard` returns `void`, if you need **both type narrowing and a returned value**, `assert` is the better choice.\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   - No `@default()` - **YOU MUST PROVIDE THE ID VALUE**\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: "# 🧠 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\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   - ✅ REQUIRED: Define all parameters inline:\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 Object.prototype.hasOwnProperty.call() for field checks**\n   - ❌ ABSOLUTELY FORBIDDEN: `Object.prototype.hasOwnProperty.call(body, \"field\")`\n   - ❌ ALSO FORBIDDEN: `body.hasOwnProperty(\"field\")`\n   - ✅ REQUIRED: Use simple patterns:\n     ```typescript\n     // For updates - simple nullish coalescing\n     field: body.field ?? undefined\n     \n     // For explicit null handling\n     field: body.field === null ? null : (body.field ?? undefined)\n     \n     // For conditional inclusion\n     ...(body.field !== undefined && { field: body.field })\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 authenticated user parameter exists**\n   - **CRITICAL RULE**: If the function receives an authenticated user (not `Record<string, never>`), it MUST use that user 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 authenticated user parameter\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 `RealizeCoderOutput` 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 interface RealizeCoderOutput {\n  plan: string;\n  prisma_schemas: string;\n  draft_without_date_type: string;\n  review: string;\n  withCompilerFeedback?: string;\n  implementationCode: string;\n}\n```\n\n### Field Descriptions\n\n* **plan**:\n  A high-level explanation of how the task will be approached. This should outline the logic and strategy *before* any code is written.\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  \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\n* **draft\\_without\\_date\\_type**:\n  A rough version of the code with special care to **never use the `Date` type**. Use `string & tags.Format<'date-time'>` or other string-based formats instead. This stage exists to validate that the type model follows the team's conventions, especially around temporal data.\n  \n  **MUST** use only fields verified to exist in the schema during the plan phase.\n\n* **review**:\n  A self-review of the draft code. This should include commentary on correctness, potential issues, or why certain trade-offs were made.\n  \n  **Should validate**: Field usage against schema, type safety, and adherence to conventions.\n\n* **withCompilerFeedback?** (optional):\n  If the draft caused TypeScript errors or warnings, include a corrected version of the code here with fixes and a brief explanation of what was changed.\n  \n  **Common fixes**: Field existence errors, type mismatches, nullable field handling.\n\n* **implementationCode**:\n  The final, production-ready implementation. This version should reflect all improvements and pass type checks, ideally without needing further revision.\n  \n  **Must guarantee**: All referenced fields exist in the schema, proper type handling, and error-free compilation.\n\n### Schema-First Planning Example\n\n```\nplan: \"\nSTEP 1 - PRISMA SCHEMA VERIFICATION:\nChecked REALIZE_CODER_ARTIFACT.md for discussionboard_user model schema:\nmodel discussionboard_user {\n  id            String   @id\n  email         String   @unique\n  password_hash String\n  display_name  String?\n  avatar_url    String?\n  is_active     Boolean  @default(true)\n  is_banned     Boolean  @default(false)\n  created_at    DateTime @default(now())\n  updated_at    DateTime @updatedAt\n}\n\nCRITICAL: Common fields that DO NOT EXIST in this model:\n- deleted_at (NO SOFT DELETE SUPPORT - will use hard delete)\n- created_by (no audit trail)\n- updated_by (no audit trail)\n- is_deleted (no soft delete flag)\n\nSTEP 2 - API SPEC VS SCHEMA VERIFICATION:\nAPI Comment requires: Soft delete with deleted_at field\nPrisma Schema has: No deleted_at field\nCONTRADICTION DETECTED: API specification requires soft delete but schema doesn't support it\n\nSTEP 3 - FIELD INVENTORY:\nConfirmed fields available for use:\n- id, email, password_hash, display_name, avatar_url\n- is_active, is_banned (Boolean flags)\n- created_at, updated_at (DateTime fields)\n\nSTEP 4 - FIELD ACCESS STRATEGY:\n- Select: Will only select fields that exist: id, email, is_active, created_at\n- Update: Can update is_active, is_banned, display_name, avatar_url\n- Delete: Must use hard delete since no deleted_at field exists\n\nSTEP 5 - TYPE COMPATIBILITY:\n- DateTime fields (created_at, updated_at): Convert using toISOStringSafe()\n- Optional fields (display_name, avatar_url): Handle null values properly\n- Use IDiscussionboardUser from ../api/structures for type safety\n\nSTEP 6 - IMPLEMENTATION DECISION:\nDue to API-Schema contradiction, will implement placeholder with typia.random<T>()\nCannot fulfill API requirements without schema modification\n\nSTEP 7 - RETURN TYPE STRATEGY:\nFunction return type is Promise<IDiscussionboardUser>\nWill NOT use satisfies on return statement - redundant with function signature\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\nThe function must always take the following **three arguments**:\n\n**Without authentication** (no decoratorEvent):\n```typescript\nexport async function something(\n  user: Record<string, never>,  // No authentication required\n  parameters: Record<string, string>,\n  body: Record<string, any>\n) {\n  ...\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\nexport async function delete__users_$id(\n  admin: AdminPayload,  // Specific type instead of generic user\n  parameters: Record<string, string>,\n  body: Record<string, any>\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: parameters.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\nThis structure must be used even for GET requests or when `parameters` or `body` are unused.\nIn such cases, define them as:\n\n```typescript\nparameters: Record<string, never>\nbody: Record<string, never>\n```\n\n> ⚠️ Do not omit any of the three arguments. All functions must include user, parameters, and body, even if some of them are unused. This ensures consistent structure and prevents runtime or compilation errors due to missing parameters.\n\n> ⚠️ When throwing errors, please use Error objects and do not use any other error formats.\n\n> 🔐 **CRITICAL User Parameter Rules**:\n> - **NO decoratorEvent**: Use `user: Record<string, never>` (empty object type)\n> - **WITH decoratorEvent**: Use the specific type from decoratorEvent (e.g., `admin: AdminPayload`)\n> - **NEVER use** `user: { id: string & tags.Format<'uuid'>, type: string }` - this is an outdated pattern\n> - The parameter name should match the role (e.g., `admin` for AdminPayload, `user` for UserPayload)\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 types or `Record<string, never>`\n3. 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     - `typia.assert<T>()` for runtime validation and type conversion\n     - `typia.assertGuard<T>()` for type narrowing with validation\n     - Custom type guards for complex validation logic\n\n    > ⚠️ Only use `as` when you can guarantee type safety. When in doubt, prefer validation over assertion.\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 `../api/structures` can be imported and used indefinitely as an exception. prioritize the use of the type defined here over the type of Prisma.\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 such as:\n   > `\"Property 'assert' does not exist on type 'typeof import(\\\"node_modules/typia/lib/tags/index\\\")'\"`\n   > \n   > **Note**: Use auto-injected modules directly (e.g., `typia.assert()`, `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. **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, mode: \"insensitive\" as const },\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\nThe following modules are **automatically injected** at the top of every generated file:\n\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- **When decoratorEvent is provided**: `import { ${decoratorType} } from \"../decorators/payload/${decoratorType}\";`\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 validated = typia.assert<IUser>(data);\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 prefer using types defined in `../api/structures` or your own explicitly implemented types when possible.\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  - Types in `../api/structures` are designed to be schema-agnostic and stable\n\n- **Mandatory Alternative: Use ../api/structures Types**  \n  Always use the interface types defined in `../api/structures` directory instead:\n\n  ```typescript\n  // ✅ CORRECT: Use stable, schema-agnostic types\n  import { IDiscussionboardModerator } from \"../api/structures/IDiscussionboardModerator\";\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  // ✅ Import from ../api/structures\n  import { IModelName } from \"../api/structures/IModelName\";\n  \n  // ✅ Use the appropriate nested interface\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**❌ 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 api/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 `user` parameter is NOT `Record<string, never>`, then EVERY operation MUST have authorization logic:\n\n### Delete Operations - OWNERSHIP IS MANDATORY\n```typescript\nexport async function delete__posts_$id(\n  user: UserPayload,  // 🔴 User parameter exists = MUST check authorization\n  parameters: { id: string & tags.Format<'uuid'> },\n  body: Record<string, never>\n) {\n  // 🔴 STEP 1: ALWAYS fetch the resource FIRST\n  const post = await MyGlobal.prisma.posts.findUniqueOrThrow({\n    where: { id: parameters.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: parameters.id },\n    data: { deleted_at: toISOStringSafe(new Date()) }\n  });\n}\n\n// ❌ WRONG - Missing authorization check\nexport async function delete__posts_$id_WRONG(\n  user: UserPayload,  // User exists but NOT USED - THIS IS FORBIDDEN\n  parameters: { id: string & tags.Format<'uuid'> },\n  body: Record<string, never>\n) {\n  // ❌ FORBIDDEN: Directly deleting without checking ownership\n  await MyGlobal.prisma.posts.update({\n    where: { id: parameters.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  user: UserPayload,\n  parameters: { id: string & tags.Format<'uuid'> },\n  body: IBoardUpdateInput\n) {\n  const board = await MyGlobal.prisma.boards.findUniqueOrThrow({\n    where: { id: parameters.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  user: UserPayload,\n  parameters: { boardId: string & tags.Format<'uuid'> },\n  body: IPostCreateInput\n) {\n  // Check if user has access to the board\n  const membership = await MyGlobal.prisma.board_members.findFirst({\n    where: {\n      board_id: parameters.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: parameters.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: parameters.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  user: Record<string, never>,  // Or specific type if authentication required\n  parameters: { id: string & tags.Format<\"uuid\"> },\n  body: Record<string, never>\n): Promise<void> {\n  // Cannot implement due to API-Schema contradiction\n  return typia.random<void>();\n}\n```\n\n### Key Rules for Contradictions:\n\n- **NEVER attempt to use fields that don't exist** in the Prisma schema\n- **NEVER ignore API specifications** - document why they can't be followed\n- **ALWAYS return `typia.random<T>()`** with comprehensive documentation\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* Never use `MyGlobal.logs.create(...)` directly — always go through `MyGlobal.prisma`.\n\n---\n\n## 📚 Prisma Usage Guide\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 types defined under `../api/structures`, 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* Receive `user`, `parameters`, and `body` from the controller\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 API structure types from `../api/structures`\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 `typia.assertGuard` or `typia.assert`:\n\n```ts\nvoid typia.assertGuard<1 | -1>(body.value);\nvalue // 1 | -1\n```\n\n```ts\nconst value = typia.assert<1 | -1>(body.value); // 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❌ **Issue with simple boolean checks**:\n```ts\nconst hasPostId = body.post_id !== undefined && body.post_id !== null;\nif (hasPostId) {\n  // TypeScript still thinks body.post_id could be null!\n  await prisma.findFirst({ where: { id: body.post_id } }); // Type error\n}\n```\n\n✅ **Fix Options**:\n\n1. **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 either a validated cast or `typia.assertGuard`:\n\n```ts\nconst id = body.id as string & tags.Format<'uuid'>; // Allowed exception\n```\n\nOR:\n\n```ts\nconst id = typia.assertGuard<string & tags.Format<'uuid'>>(body.id);\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 `../api/structures` 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 `../api/structures` 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 ../api/structures types for field validation\nimport { IModel } from \"../api/structures/IModel\";\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 ../api/structures types for update operations\n\n**DO:**\n\n```ts\nimport { IUserRoles } from \"../api/structures/IUserRoles\";\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 ../api/structures types, never Prisma generated types\n\nAPI structure types from `../api/structures` 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\nimport { IUserRoles } from \"../api/structures/IUserRoles\";\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\nimport { IUserRoles } from \"../api/structures/IUserRoles\";\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, mode: \"insensitive\" as const }\n    }),\n    ...(description && description.length > 0 && { \n      description: { contains: description, mode: \"insensitive\" as const }\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 `../api/structures` types only            |\n| Assign `null` to non-nullable fields       | Use `?? undefined` or omit                     |\n| Use Prisma types for update operations     | Use `IModel.IUpdate` from api/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 `../api/structures` 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 `../api/structures` 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 api/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### 🔧 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        mode: \"insensitive\" as const,\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# 🔐 Browser-Compatible Native-First Rule\n\nYou must implement all functionality using **only browser-compatible native features** whenever possible.  \nAll logic must assume it will run in a browser environment — even if Node.js is also supported.\n\n> 🚫 Do **not** use Node.js-only modules like `'crypto'`, `'fs'`, `'path'`, etc.\n> ✅ Always use **Web-standard, browser-safe APIs**.\n\n---\n\n## ✅ Encryption Rule\n\nAll encryption and decryption must be implemented using the **Web Crypto API (`window.crypto.subtle`)**.\n\n**❌ Do not use:**\n- `crypto` (Node.js built-in)\n- `crypto-js`, `bcrypt`, `libsodium`, or any other third-party crypto libraries\n\n**✅ Only use:**\n- `window.crypto.subtle` and `window.crypto.getRandomValues`\n\n```ts\n// Example: AES-GCM encryption in the browser\nconst key = await crypto.subtle.generateKey(\n  { name: 'AES-GCM', length: 256 },\n  true,\n  ['encrypt', 'decrypt']\n);\n\nconst iv = crypto.getRandomValues(new Uint8Array(12));\n\nconst encoded = new TextEncoder().encode('hello world');\nconst encrypted = await crypto.subtle.encrypt(\n  { name: 'AES-GCM', iv },\n  key,\n  encoded\n);\n````\n\n---\n\n## ✅ General API Rule\n\nYou must avoid Node.js-specific or third-party libraries. All implementations must be fully functional in **browser environments**, using **web-standard APIs** only.\n\n| Use Case        | ❌ Do Not Use (Node.js / External)                 | ✅ Use Instead (Browser-safe)               |\n| --------------- | ------------------------------------------------- | ------------------------------------------ |\n| UUID Generation | `uuid` package, `crypto.randomUUID()` (Node only) | `crypto.randomUUID()` (browser supported)  |\n| HTTP Requests   | `axios`, `node-fetch`                             | `fetch`                                    |\n| Timing / Delay  | `sleep-promise`, `delay`                          | `setTimeout`, `await new Promise(...)`     |\n| Hashing         | `crypto.createHash()` (Node.js)                   | `crypto.subtle.digest()`                   |\n| Compression     | `zlib`, `adm-zip`, `archiver`                     | `CompressionStream`, `DecompressionStream` |\n| File Handling   | `fs`, `fs-extra`                                  | `File`, `Blob`, `FileReader`, `Streams`    |\n\n---\n\n## 🧷 Summary\n\n* ✅ Use only APIs that work natively in **browsers**.\n* 🚫 Do not use Node.js-only modules or platform-specific packages.\n* ❌ Avoid third-party libraries unless there's **no equivalent** browser-native solution.\n* 🧭 If your logic must run both in Node.js and the browser, **the browser must always be the lowest common denominator**—ensure everything works in the browser first.\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## 🔧 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## 🎯 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## 🛡️ `typia.assert` vs `typia.assertGuard`\n\n`typia` provides two main runtime validation utilities: `assert` and `assertGuard`.\nBoth serve to validate runtime data against a TypeScript type, but their **behavior and return types differ**, which can influence which one to use depending on your use case.\n\n### 🔍 `typia.assert<T>(input): T`\n\n* Validates that `input` conforms to type `T`.\n* If invalid, throws a detailed exception.\n* **Returns** the parsed and validated input as type `T`.\n* Ideal when you want **to validate and use the result immediately**.\n\n**Example:**\n\n```ts\nconst user = typia.assert<IUser>(input); // user is of type IUser\n```\n\n---\n\n### 🧪 `typia.assertGuard<T>(input): void`\n\n* Validates that `input` conforms to type `T`.\n* If invalid, throws an exception like `assert`.\n* **Does not return anything** (`void` return type).\n* Acts like a **type guard** for the input **within the scope**.\n* Useful when you want to narrow the type **for subsequent logic**, but **don't need to reassign the value**.\n\n**Example:**\n\n```ts\ntypia.assertGuard<IUser>(input); // input is now treated as IUser\n\n// input can be used safely as IUser here\nconsole.log(input.username);\n```\n\n### 📎 Appendix – `assert` vs `assertGuard`\n\n```ts\n/**\n * Asserts a value type.\n *\n * Asserts a parametric value type and throws a {@link TypeGuardError} with detailed\n * reason, if the parametric value is not following the type `T`. Otherwise, the\n * value is following the type `T`, just input parameter would be returned.\n *\n * If what you want is not asserting but just knowing whether the parametric value is\n * following the type `T` or not, you can choose the {@link is} function instead.\n * Otherwise you want to know all the errors, {@link validate} is the way to go.\n * Also, if you want to automatically cast the parametric value to the type `T`\n * when no problem (perform the assertion guard of type).\n *\n * On the other and, if you don't want to allow any superfluous property that is not\n * enrolled to the type `T`, you can use {@link assertEquals} function instead.\n *\n * @template T Type of the input value\n * @param input A value to be asserted\n * @param errorFactory Custom error factory. Default is `TypeGuardError`\n * @returns Parametric input value\n * @throws A {@link TypeGuardError} instance with detailed reason\n *\n * @author Jeongho Nam - https://github.com/samchon\n */\nexport declare function assert<T>(input: T, errorFactory?: undefined | ((props: TypeGuardError.IProps) => Error)): T;\n/**\n * Asserts a value type.\n *\n * Asserts a parametric value type and throws a {@link TypeGuardError} with detailed\n * reason, if the parametric value is not following the type `T`. Otherwise, the\n * value is following the type `T`, just input parameter would be returned.\n *\n * If what you want is not asserting but just knowing whether the parametric value is\n * following the type `T` or not, you can choose the {@link is} function instead.\n * Otherwise, you want to know all the errors, {@link validate} is the way to go.\n *\n * On the other and, if you don't want to allow any superfluous property that is not\n * enrolled to the type `T`, you can use {@link assertEquals} function instead.\n *\n * @template T Type of the input value\n * @param input A value to be asserted\n * @param errorFactory Custom error factory. Default is `TypeGuardError`\n * @returns Parametric input value casted as `T`\n * @throws A {@link TypeGuardError} instance with detailed reason\n *\n * @author Jeongho Nam - https://github.com/samchon\n */\nexport declare function assert<T>(input: unknown, errorFactory?: undefined | ((props: TypeGuardError.IProps) => Error)): T;\n/**\n * Assertion guard of a value type.\n *\n * Asserts a parametric value type and throws a {@link TypeGuardError} with detailed\n * reason, if the parametric value is not following the type `T`. Otherwise, the\n * value is following the type `T`, nothing would be returned, but the input value\n * would be automatically casted to the type `T`. This is the concept of\n * \"Assertion Guard\" of a value type.\n *\n * If what you want is not asserting but just knowing whether the parametric value is\n * following the type `T` or not, you can choose the {@link is} function instead.\n * Otherwise you want to know all the errors, {@link validate} is the way to go.\n * Also, if you want to returns the parametric value when no problem, you can use\n * {@link assert} function instead.\n *\n * On the other and, if you don't want to allow any superfluous property that is not\n * enrolled to the type `T`, you can use {@link assertGuardEquals} function instead.\n *\n * @template T Type of the input value\n * @param input A value to be asserted\n * @param errorFactory Custom error factory. Default is `TypeGuardError`\n * @throws A {@link TypeGuardError} instance with detailed reason\n *\n * @author Jeongho Nam - https://github.com/samchon\n */\nexport declare function assertGuard<T>(input: T, errorFactory?: undefined | ((props: TypeGuardError.IProps) => Error)): asserts input is T;\n/**\n * Assertion guard of a value type.\n *\n * Asserts a parametric value type and throws a {@link TypeGuardError} with detailed\n * reason, if the parametric value is not following the type `T`. Otherwise, the\n * value is following the type `T`, nothing would be returned, but the input value\n * would be automatically casted to the type `T`. This is the concept of\n * \"Assertion Guard\" of a value type.\n *\n * If what you want is not asserting but just knowing whether the parametric value is\n * following the type `T` or not, you can choose the {@link is} function instead.\n * Otherwise you want to know all the errors, {@link validate} is the way to go.\n * Also, if you want to returns the parametric value when no problem, you can use\n * {@link assert} function instead.\n *\n * On the other and, if you don't want to allow any superfluous property that is not\n * enrolled to the type `T`, you can use {@link assertGuardEquals} function instead.\n *\n * @template T Type of the input value\n * @param input A value to be asserted\n * @param errorFactory Custom error factory. Default is `TypeGuardError`\n * @throws A {@link TypeGuardError} instance with detailed reason\n *\n * @author Jeongho Nam - https://github.com/samchon\n */\nexport declare function assertGuard<T>(input: unknown, errorFactory?: undefined | ((props: TypeGuardError.IProps) => Error)): asserts input is T;\n\n```\n\n### Handling Typia Assertion 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 **typia.assert** to explicitly assert or validate the value conforms to the expected `uint32` format.\n- Example:\n\n```ts\nconst value = getValue(); // type: number & tags.Type<\"int32\">\n\ntypia.assert<number & tags.Type<\"int32\"> & tags.JsonSchemaPlugin<{ format: \"uint32\" }>>(value);\n\n// Now `value` is guaranteed to conform to the expected unsigned 32-bit integer type.\n```\n\n* Always use typia.tags' `assert` or related functions for runtime validation and to satisfy TypeScript's type checker.\n* This approach ensures type safety without compromising runtime correctness.\n\n---\n\n### ✅ Summary: Which Should I Use?\n\n| Use Case                             | Recommended API          |\n| ------------------------------------ | ------------------------ |\n| Validate and return typed value      | `typia.assert<T>()`      |\n| Narrow type without reassigning      | `typia.assertGuard<T>()` |\n| Use validated object directly        | `typia.assert<T>()`      |\n| Use input inside a conditional block | `typia.assertGuard<T>()` |\n\n> **Note:** Since `assertGuard` returns `void`, if you need **both type narrowing and a returned value**, `assert` is the better choice.\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   - No `@default()` - **YOU MUST PROVIDE THE ID VALUE**\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."
     }, {
         id: v4(),
         created_at: (new Date).toISOString(),
         type: "systemMessage",
-        text: props.decoratorEvent ? [ "Decorator-related files are already generated at the following locations:", `- Decorator implementation: decorators/${props.decoratorEvent.decorator.name}.ts`, `  - NestJS parameter decorator`, `  - When importing from providers folder, use: '../decorators/${props.decoratorEvent.decorator.name}'`, `- Authentication provider: authentications/${props.decoratorEvent.provider.name}.ts`, `  - Contains JWT validation, role checking, and authorization logic`, `  - When importing from providers folder, use: '../authentications/${props.decoratorEvent.provider.name}'`, `- Type definition: authentications/types/${props.decoratorEvent.payload.name}.ts`, `  - TypeScript interface for authenticated user payload`, `  - When importing from providers folder, use: '../authentications/types/${props.decoratorEvent.payload.name}'` ].join("\n") : ""
+        text: props.decoratorEvent ? [ "Decorator-related files are already generated at the following locations:", `- Decorator implementation: decorators/${props.decoratorEvent.decorator.name}.ts`, `  - NestJS parameter decorator`, `  - When importing from providers folder, use: '../decorators/${props.decoratorEvent.decorator.name}'`, `- Authentication provider: decorators/${props.decoratorEvent.provider.name}.ts`, `  - Contains JWT validation, role checking, and authorization logic`, `  - When importing from providers folder, use: '../decorators/${props.decoratorEvent.provider.name}'`, `- Type definition: decorators/payload/${props.decoratorEvent.payload.name}.ts`, `  - TypeScript interface for authenticated user payload`, `  - When importing from providers folder, use: '../decorators/payload/${props.decoratorEvent.payload.name}'` ].join("\n") : ""
     }, {
         id: v4(),
         created_at: (new Date).toISOString(),
@@ -7962,18 +8383,24 @@ const transformRealizeCoderHistories = (state, props, artifacts, previous, diagn
     } ];
 };
 
+var RealizeFileSystem;
+
+(function(RealizeFileSystem) {
+    RealizeFileSystem.providerPath = filename => `src/providers/${filename}.ts`;
+})(RealizeFileSystem || (RealizeFileSystem = {}));
+
 function replaceImportStatements(ctx) {
     return async function(code, decoratorType) {
         const compiler = await ctx.compiler();
         code = await compiler.typescript.beautify(code);
         code = code.replace(/import\s*{\s*MyGlobal\s*}\s*from\s*["']\.\.\/MyGlobal["']\s*;?\s*/gm, "").replace(/import\s+typia\s*,\s*{\s*tags\s*}\s*from\s*["']typia["']\s*;?\s*/gm, "").replace(/import\s*{\s*tags\s*}\s*from\s*["']typia["']\s*;?\s*/gm, "").replace(/import\s*{\s*tags\s*,\s*typia\s*}\s*from\s*["']typia["']\s*;?\s*/gm, "").replace(/import\s+typia\s*from\s*["']typia["']\s*;?\s*/gm, "").replace(/import\s*{\s*Prisma\s*}\s*from\s*["']@prisma\/client["']\s*;?\s*/gm, "").replace(/import\s*{\s*v4\s*}\s*from\s*["']uuid["']\s*;?\s*/gm, "").replace(/import\s*{\s*toISOStringSafe\s*}\s*from\s*["']\.\.\/util\/toISOStringSafe["']\s*;?\s*/gm, "");
         if (decoratorType) {
-            const decoratorTypeRegex = new RegExp(`import\\s*{\\s*${decoratorType}\\s*}\\s*from\\s*["']\\.\\./authentications/types/${decoratorType}["']\\s*;?\\s*`, "gm");
+            const decoratorTypeRegex = new RegExp(`import\\s*{\\s*${decoratorType}\\s*}\\s*from\\s*["']\\.\\./decorators/payload/${decoratorType}["']\\s*;?\\s*`, "gm");
             code = code.replace(decoratorTypeRegex, "");
         }
         const imports = [ 'import { MyGlobal } from "../MyGlobal";', 'import typia, { tags } from "typia";', 'import { Prisma } from "@prisma/client";', 'import { v4 } from "uuid";', 'import { toISOStringSafe } from "../util/toISOStringSafe"' ];
         if (decoratorType) {
-            imports.push(`import { ${decoratorType} } from "../authentications/types/${decoratorType}"`);
+            imports.push(`import { ${decoratorType} } from "../decorators/payload/${decoratorType}"`);
         }
         code = [ ...imports, "", code ].join("\n");
         code = code.replace(/^\s+$/gm, "").replace(/\n{3,}/g, "\n\n").replace(/(import.*?;)(\s*)(\n(?!import|\s*$))/g, "$1\n\n$3").trim() + "\n";
@@ -8006,7 +8433,6 @@ const orchestrateRealizeCoder = async (ctx, operation, props, previous, total, d
         vendor: ctx.vendor,
         config: {
             ...ctx.config,
-            backoffStrategy: randomBackoffStrategy,
             executor: {
                 describe: null
             }
@@ -8025,7 +8451,7 @@ const orchestrateRealizeCoder = async (ctx, operation, props, previous, total, d
     pointer.value.implementationCode = pointer.value.implementationCode.replaceAll("typia.tags.assert", "typia.assert");
     return {
         ...pointer.value,
-        filename: `src/providers/${props.functionName}.ts`
+        filename: RealizeFileSystem.providerPath(props.functionName)
     };
 };
 
@@ -8345,17 +8771,12 @@ const orchestrateRealizePlanner = async (ctx, operation, authorization) => {
 };
 
 async function writeCodeUntilCompilePassed(ctx, ops, authorizations, retry) {
-    const payloads = authorizations.map((el => ({
-        [el.payload.location]: el.payload.content
-    }))).reduce(((acc, cur) => Object.assign(acc, cur)), {});
-    const files = Object.entries(await ctx.files({
+    const payloads = arrayToRecord(authorizations.map((el => el.payload)), "location", "content");
+    const files = arrayToRecord(Object.entries(await ctx.files({
         dbms: "postgres"
-    })).filter((([key]) => key.startsWith("src"))).reduce(((acc, [filename, content]) => Object.assign(acc, {
-        [filename]: content
-    })), {});
-    const templateFiles = [ "src/MyGlobal.ts", "src/util/toISOStringSafe.ts" ];
+    })).filter((([key]) => key.startsWith("src"))));
     const entireCodes = {
-        ...await loadTemplateFiles(templateFiles)
+        ...await loadTemplateFiles(ctx)
     };
     let diagnostics = {
         current: [],
@@ -8394,9 +8815,7 @@ async function writeCodeUntilCompilePassed(ctx, ops, authorizations, retry) {
                 ...payloads,
                 ...files,
                 ...nodeModules,
-                ...Object.entries(entireCodes).map((([filename, {content}]) => ({
-                    [filename]: content
-                }))).reduce(((acc, cur) => Object.assign(acc, cur)), {})
+                ...arrayToRecord(Object.entries(entireCodes).map((([filename, {content}]) => [ filename, content ])))
             }
         });
         if (compiled.type === "success" && generatedCodes.every((c => c.type === "success"))) {
@@ -8407,7 +8826,7 @@ async function writeCodeUntilCompilePassed(ctx, ops, authorizations, retry) {
             console.log(JSON.stringify(diagnostics.current, null, 2), `현재 에러의 수: ${diagnostics.current.length}\n`, `현재 시도 수: ${i + 1}`);
         }
     }
-    return Object.entries(entireCodes).filter((([filename]) => filename.startsWith("src/providers"))).map((([filename, value]) => ({
+    return Object.entries(entireCodes).map((([filename, value]) => ({
         filename,
         content: value.content,
         endpoint: value.endpoint,
@@ -8417,14 +8836,13 @@ async function writeCodeUntilCompilePassed(ctx, ops, authorizations, retry) {
     })));
 }
 
-async function loadTemplateFiles(templateFiles) {
-    const templateBasePath = path.join(__dirname, "../../../../../internals/template/realize");
+async function loadTemplateFiles(ctx) {
+    const templateFiles = await (await ctx.compiler()).realize.getTemplate();
+    const targets = [ "src/MyGlobal.ts", "src/util/toISOStringSafe.ts" ];
     const result = {};
-    for (const filePath of templateFiles) {
+    for (const filePath of targets) {
         result[filePath] = {
-            content: await readFile(path.join(templateBasePath, filePath), {
-                encoding: "utf-8"
-            }),
+            content: templateFiles[filePath],
             result: "success",
             location: filePath,
             role: null
@@ -8435,7 +8853,7 @@ async function loadTemplateFiles(templateFiles) {
 
 async function process$1(ctx, metadata, op, diagnostics, entireCodes, decorator) {
     const result = await pipe(op, (op => orchestrateRealizePlanner(ctx, op, decorator)), (async p => {
-        const filename = `src/providers/${p.functionName}.ts`;
+        const filename = RealizeFileSystem.providerPath(p.functionName);
         const t = diagnostics.total.filter((el => el.file === filename));
         const d = diagnostics.current.filter((el => el.file === filename));
         const c = entireCodes[filename]?.content ?? null;
@@ -8496,7 +8914,7 @@ const orchestrateRealize = ctx => async props => {
         step: ctx.state().test?.step ?? 0
     });
     const authorizations = await orchestrateRealizeAuthorization(ctx);
-    const files = await writeCodeUntilCompilePassed(ctx, ops, authorizations, 2);
+    const files = await writeCodeUntilCompilePassed(ctx, ops, authorizations, 3);
     const now = (new Date).toISOString();
     const realize = ctx.state().realize;
     if (realize !== null) {
@@ -8507,7 +8925,16 @@ const orchestrateRealize = ctx => async props => {
             compiled: {
                 type: "success"
             },
-            functions: files,
+            functions: {
+                ...files,
+                ...authorizations.flatMap((el => [ {
+                    [el.decorator.location]: el.decorator.content
+                }, {
+                    [el.payload.location]: el.payload.content
+                }, {
+                    [el.payload.location]: el.payload.content
+                } ])).reduce(((acc, cur) => Object.assign(acc, cur)))
+            },
             completed_at: now,
             created_at: now,
             id: v4(),
@@ -8582,8 +9009,9 @@ function transformTestWriteHistories(scenario, artifacts) {
                     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.",
-                            type: "string"
+                            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\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",
@@ -9087,7 +9515,8 @@ const execute = async (ctx, dict, endpointNotFound, entire, include, exclude) =>
         ctx.usage().record(tokenUsage, [ "test" ]);
     }));
     if (pointer.value.length === 0) {
-        throw new Error("Failed to create test plans.");
+        console.error("Failed to create test plans. No function called.");
+        return [];
     }
     return pointer.value;
 };
@@ -9119,7 +9548,7 @@ function createApplication$1(props) {
         const result = (() => {
             const _io0 = input => 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) && input.scenarios.every((elem => "object" === typeof elem && null !== elem && _io3(elem))));
-            const _io2 = input => "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method);
+            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) => [ (Array.isArray(input.scenarioGroups) || _report(_exceptionable, {
@@ -9164,9 +9593,13 @@ function createApplication$1(props) {
                 expected: "Array<IAutoBeTestScenarioApplication.IScenario>",
                 value: input.scenarios
             }) ].every((flag => flag));
-            const _vo2 = (input, _path, _exceptionable = true) => [ "string" === typeof input.path || _report(_exceptionable, {
+            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",
+                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",
@@ -9338,8 +9771,9 @@ const claude$2 = {
                     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.",
-                            type: "string"
+                            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\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",
@@ -9400,7 +9834,7 @@ const claude$2 = {
         validate: (() => {
             const _io0 = input => 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) && input.scenarios.every((elem => "object" === typeof elem && null !== elem && _io3(elem))));
-            const _io2 = input => "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method);
+            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) => [ (Array.isArray(input.scenarioGroups) || _report(_exceptionable, {
@@ -9445,9 +9879,13 @@ const claude$2 = {
                 expected: "Array<IAutoBeTestScenarioApplication.IScenario>",
                 value: input.scenarios
             }) ].every((flag => flag));
-            const _vo2 = (input, _path, _exceptionable = true) => [ "string" === typeof input.path || _report(_exceptionable, {
+            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",
+                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",
@@ -9574,7 +10012,7 @@ const collection$2 = {
                         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.",
+                                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: {
@@ -9627,7 +10065,7 @@ const collection$2 = {
             validate: (() => {
                 const _io0 = input => 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) && input.scenarios.every((elem => "object" === typeof elem && null !== elem && _io3(elem))));
-                const _io2 = input => "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method);
+                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) => [ (Array.isArray(input.scenarioGroups) || _report(_exceptionable, {
@@ -9672,9 +10110,13 @@ const collection$2 = {
                     expected: "Array<IAutoBeTestScenarioApplication.IScenario>",
                     value: input.scenarios
                 }) ].every((flag => flag));
-                const _vo2 = (input, _path, _exceptionable = true) => [ "string" === typeof input.path || _report(_exceptionable, {
+                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",
+                    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",
@@ -11302,7 +11744,7 @@ const sleepMap = {
     interfaceStart: 1e3,
     interfaceEndpoints: 1e3,
     interfaceOperations: 400,
-    interfaceComponents: 400,
+    interfaceSchemas: 400,
     interfaceComplement: 2e3,
     interfaceComplete: 1e3,
     testStart: 1e3,