@autobe/agent 0.0.0 → 0.3.9

package/lib/factory/createAutoBeApplication.js

@@ -0,0 +1,1195 @@
+"use strict";
+var __createBinding = (this && this.__createBinding) || (Object.create ? (function(o, m, k, k2) {
+    if (k2 === undefined) k2 = k;
+    var desc = Object.getOwnPropertyDescriptor(m, k);
+    if (!desc || ("get" in desc ? !m.__esModule : desc.writable || desc.configurable)) {
+      desc = { enumerable: true, get: function() { return m[k]; } };
+    }
+    Object.defineProperty(o, k2, desc);
+}) : (function(o, m, k, k2) {
+    if (k2 === undefined) k2 = k;
+    o[k2] = m[k];
+}));
+var __setModuleDefault = (this && this.__setModuleDefault) || (Object.create ? (function(o, v) {
+    Object.defineProperty(o, "default", { enumerable: true, value: v });
+}) : function(o, v) {
+    o["default"] = v;
+});
+var __importStar = (this && this.__importStar) || (function () {
+    var ownKeys = function(o) {
+        ownKeys = Object.getOwnPropertyNames || function (o) {
+            var ar = [];
+            for (var k in o) if (Object.prototype.hasOwnProperty.call(o, k)) ar[ar.length] = k;
+            return ar;
+        };
+        return ownKeys(o);
+    };
+    return function (mod) {
+        if (mod && mod.__esModule) return mod;
+        var result = {};
+        if (mod != null) for (var k = ownKeys(mod), i = 0; i < k.length; i++) if (k[i] !== "default") __createBinding(result, mod, k[i]);
+        __setModuleDefault(result, mod);
+        return result;
+    };
+})();
+var __importDefault = (this && this.__importDefault) || function (mod) {
+    return (mod && mod.__esModule) ? mod : { "default": mod };
+};
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.createAutoBeController = void 0;
+const __typia_transform__validateReport = __importStar(require("typia/lib/internal/_validateReport.js"));
+const typia_1 = __importDefault(require("typia"));
+const assertSchemaModel_1 = require("../context/assertSchemaModel");
+const orchestrateInterface_1 = require("../orchestrate/interface/orchestrateInterface");
+const orchestrateAnalyze_1 = require("../orchestrate/orchestrateAnalyze");
+const orchestrateRealize_1 = require("../orchestrate/orchestrateRealize");
+const orchestrateTest_1 = require("../orchestrate/orchestrateTest");
+const orchestratePrisma_1 = require("../orchestrate/prisma/orchestratePrisma");
+const createAutoBeController = (props) => {
+    (0, assertSchemaModel_1.assertSchemaModel)(props.model);
+    const application = collection[props.model];
+    return {
+        protocol: "class",
+        name: "autobe",
+        application,
+        execute: {
+            analyze: (0, orchestrateAnalyze_1.orchestrateAnalyze)(props.context),
+            prisma: (0, orchestratePrisma_1.orchestratePrisma)(props.context),
+            interface: (0, orchestrateInterface_1.orchestrateInterface)(props.context),
+            test: (0, orchestrateTest_1.orchestrateTest)(props.context),
+            realize: (0, orchestrateRealize_1.orchestrateRealize)(props.context),
+        },
+    };
+};
+exports.createAutoBeController = createAutoBeController;
+const claude = {
+    model: "claude",
+    options: {
+        reference: true,
+        separate: null
+    },
+    functions: [
+        {
+            name: "analyze",
+            parameters: {
+                description: "Current Type: {@link IAutoBeApplicationProps}",
+                type: "object",
+                properties: {
+                    reason: {
+                        title: "The reason of the function call",
+                        description: "The reason of the function call.",
+                        type: "string"
+                    },
+                    userPlanningRequirements: {
+                        title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
+                        description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>",
+                        type: "string"
+                    }
+                },
+                required: [
+                    "reason"
+                ],
+                additionalProperties: false,
+                $defs: {}
+            },
+            output: {
+                description: "Current Type: {@link IAutoBeApplicationResult}",
+                type: "object",
+                properties: {
+                    success: {
+                        type: "boolean"
+                    }
+                },
+                required: [
+                    "success"
+                ]
+            },
+            description: "Run Analyze Agent.\n\nExecutes the Analyze agent to process user requirements and generate a\nstructured specification document. This agent analyzes all conversation\nhistory between users and AI, separates business logic from technical\nrequirements, and establishes development priorities and scope.\n\n**IMPORTANT**: Only call this function when sufficient requirements have\nbeen discussed to generate a comprehensive specification. The context must\ncontain enough detail about the system's purpose, core features, data\nmodels, and business rules. If requirements are unclear or incomplete,\ncontinue gathering information through conversation instead.\n\nThe agent will automatically generate follow-up questions for any ambiguous\nrequirements and continuously refine its understanding through iterative\nconversation. When executed after other agents have generated code, it can\nalso interpret change requests in the context of existing implementations.",
+            validate: (() => { const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements); const _vo0 = (input, _path, _exceptionable = true) => ["string" === typeof input.reason || _report(_exceptionable, {
+                    path: _path + ".reason",
+                    expected: "string",
+                    value: input.reason
+                }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
+                    path: _path + ".userPlanningRequirements",
+                    expected: "(string | undefined)",
+                    value: input.userPlanningRequirements
+                })].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: "IAutoBeApplicationProps",
+                        value: input
+                    })) && _vo0(input, _path + "", true) || _report(true, {
+                        path: _path + "",
+                        expected: "IAutoBeApplicationProps",
+                        value: input
+                    }))(input, "$input", true);
+                    const success = 0 === errors.length;
+                    return success ? {
+                        success,
+                        data: input
+                    } : {
+                        success,
+                        errors,
+                        data: input
+                    };
+                }
+                return {
+                    success: true,
+                    data: input
+                };
+            }; })()
+        },
+        {
+            name: "prisma",
+            parameters: {
+                description: "Current Type: {@link IAutoBeApplicationProps}",
+                type: "object",
+                properties: {
+                    reason: {
+                        title: "The reason of the function call",
+                        description: "The reason of the function call.",
+                        type: "string"
+                    },
+                    userPlanningRequirements: {
+                        title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
+                        description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>",
+                        type: "string"
+                    }
+                },
+                required: [
+                    "reason"
+                ],
+                additionalProperties: false,
+                $defs: {}
+            },
+            output: {
+                description: "Current Type: {@link IAutoBeApplicationResult}",
+                type: "object",
+                properties: {
+                    success: {
+                        type: "boolean"
+                    }
+                },
+                required: [
+                    "success"
+                ]
+            },
+            description: "Run prisma agent.\n\nExecutes the Prisma agent to generate database schema files and ERD\ndocumentation. This agent reads the requirements specification created by\nthe {@link analyze Analyze agent} and produces a complete Prisma schema with\ncomprehensive documentation for each entity and attribute.\n\n**PREREQUISITE**: Only call this function after the {@link analyze} function\nhas been successfully executed and a requirements specification document\nhas been generated. The Prisma agent depends on the structured requirements\nanalysis to design the database schema properly. Without a completed\nrequirements specification, this function should NOT be called.\n\nThe agent will automatically validate the generated schema using the Prisma\ncompiler, self-correct any compilation errors through feedback loops, and\ngenerate ERD documentation using prisma-markdown. An internal review\nprocess ensures schema quality and optimization.",
+            validate: (() => { const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements); const _vo0 = (input, _path, _exceptionable = true) => ["string" === typeof input.reason || _report(_exceptionable, {
+                    path: _path + ".reason",
+                    expected: "string",
+                    value: input.reason
+                }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
+                    path: _path + ".userPlanningRequirements",
+                    expected: "(string | undefined)",
+                    value: input.userPlanningRequirements
+                })].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: "IAutoBeApplicationProps",
+                        value: input
+                    })) && _vo0(input, _path + "", true) || _report(true, {
+                        path: _path + "",
+                        expected: "IAutoBeApplicationProps",
+                        value: input
+                    }))(input, "$input", true);
+                    const success = 0 === errors.length;
+                    return success ? {
+                        success,
+                        data: input
+                    } : {
+                        success,
+                        errors,
+                        data: input
+                    };
+                }
+                return {
+                    success: true,
+                    data: input
+                };
+            }; })()
+        },
+        {
+            name: "interface",
+            parameters: {
+                description: "Current Type: {@link IAutoBeApplicationProps}",
+                type: "object",
+                properties: {
+                    reason: {
+                        title: "The reason of the function call",
+                        description: "The reason of the function call.",
+                        type: "string"
+                    },
+                    userPlanningRequirements: {
+                        title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
+                        description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>",
+                        type: "string"
+                    }
+                },
+                required: [
+                    "reason"
+                ],
+                additionalProperties: false,
+                $defs: {}
+            },
+            output: {
+                description: "Current Type: {@link IAutoBeApplicationResult}",
+                type: "object",
+                properties: {
+                    success: {
+                        type: "boolean"
+                    }
+                },
+                required: [
+                    "success"
+                ]
+            },
+            description: "Run interface agent.\n\nExecutes the Interface agent to design and generate API interfaces. This\nagent creates OpenAPI schemas and TypeScript/NestJS code based on the\nrequirements specification and ERD documentation from previous agents.\n\nThe agent follows a sophisticated pipeline: first constructing formal\nOpenAPI Operation Schemas and JSON Schemas, then validating these schemas,\nand finally transforming them into NestJS controllers and DTOs. Each\ngenerated interface includes comprehensive JSDoc comments and undergoes\ninternal review for consistency.",
+            validate: (() => { const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements); const _vo0 = (input, _path, _exceptionable = true) => ["string" === typeof input.reason || _report(_exceptionable, {
+                    path: _path + ".reason",
+                    expected: "string",
+                    value: input.reason
+                }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
+                    path: _path + ".userPlanningRequirements",
+                    expected: "(string | undefined)",
+                    value: input.userPlanningRequirements
+                })].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: "IAutoBeApplicationProps",
+                        value: input
+                    })) && _vo0(input, _path + "", true) || _report(true, {
+                        path: _path + "",
+                        expected: "IAutoBeApplicationProps",
+                        value: input
+                    }))(input, "$input", true);
+                    const success = 0 === errors.length;
+                    return success ? {
+                        success,
+                        data: input
+                    } : {
+                        success,
+                        errors,
+                        data: input
+                    };
+                }
+                return {
+                    success: true,
+                    data: input
+                };
+            }; })()
+        },
+        {
+            name: "test",
+            parameters: {
+                description: "Current Type: {@link IAutoBeApplicationProps}",
+                type: "object",
+                properties: {
+                    reason: {
+                        title: "The reason of the function call",
+                        description: "The reason of the function call.",
+                        type: "string"
+                    },
+                    userPlanningRequirements: {
+                        title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
+                        description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>",
+                        type: "string"
+                    }
+                },
+                required: [
+                    "reason"
+                ],
+                additionalProperties: false,
+                $defs: {}
+            },
+            output: {
+                description: "Current Type: {@link IAutoBeApplicationResult}",
+                type: "object",
+                properties: {
+                    success: {
+                        type: "boolean"
+                    }
+                },
+                required: [
+                    "success"
+                ]
+            },
+            description: "Run test program agent.\n\nExecutes the Test agent to generate comprehensive E2E test suites for all\n{@link interface API interfaces}. This agent synthesizes outputs from\nprevious agents to create tests that validate both individual endpoints and\ntheir interactions.\n\n**PREREQUISITE**: Only call this function after the {@link interface}\nfunction has been successfully executed and API interfaces have been\ngenerated. The Test agent requires the completed API interface definitions,\nOpenAPI schemas, and TypeScript code to generate appropriate test\nscenarios. Without completed interface design, this function should NOT be\ncalled.\n\nThe agent will analyze dependency relationships between API functions,\nstructure integrated test scenarios with correct execution sequences, and\nenhance pre-generated test scaffolds with business logic validation.\nTypeScript compiler validation and internal review ensure test quality and\noptimal coverage.",
+            validate: (() => { const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements); const _vo0 = (input, _path, _exceptionable = true) => ["string" === typeof input.reason || _report(_exceptionable, {
+                    path: _path + ".reason",
+                    expected: "string",
+                    value: input.reason
+                }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
+                    path: _path + ".userPlanningRequirements",
+                    expected: "(string | undefined)",
+                    value: input.userPlanningRequirements
+                })].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: "IAutoBeApplicationProps",
+                        value: input
+                    })) && _vo0(input, _path + "", true) || _report(true, {
+                        path: _path + "",
+                        expected: "IAutoBeApplicationProps",
+                        value: input
+                    }))(input, "$input", true);
+                    const success = 0 === errors.length;
+                    return success ? {
+                        success,
+                        data: input
+                    } : {
+                        success,
+                        errors,
+                        data: input
+                    };
+                }
+                return {
+                    success: true,
+                    data: input
+                };
+            }; })()
+        },
+        {
+            name: "realize",
+            parameters: {
+                description: "Current Type: {@link IAutoBeApplicationProps}",
+                type: "object",
+                properties: {
+                    reason: {
+                        title: "The reason of the function call",
+                        description: "The reason of the function call.",
+                        type: "string"
+                    },
+                    userPlanningRequirements: {
+                        title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
+                        description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>",
+                        type: "string"
+                    }
+                },
+                required: [
+                    "reason"
+                ],
+                additionalProperties: false,
+                $defs: {}
+            },
+            output: {
+                description: "Current Type: {@link IAutoBeApplicationResult}",
+                type: "object",
+                properties: {
+                    success: {
+                        type: "boolean"
+                    }
+                },
+                required: [
+                    "success"
+                ]
+            },
+            description: "Run realize agent.\n\nExecutes the Realize agent to implement the actual business logic for each\nAPI endpoint. This agent synthesizes all outputs from previous agents to\ngenerate fully functional service provider code.\n\n**PREREQUISITE**: Only call this function after the {@link interface}\nfunction has been successfully executed and API interfaces have been\ngenerated. The Realize agent requires the completed API interface\ndefinitions to implement the corresponding service logic. It also benefits\nfrom having test code available for validation. Without completed interface\ndesign, this function should NOT be called.\n\nThe agent will create service implementations with multiple validation\nlayers: TypeScript compiler feedback, runtime validation through test\nexecution, and quality optimization through internal review. The generated\ncode handles database interactions through Prisma, implements security and\nvalidation checks, and processes business rules according to\nspecifications.",
+            validate: (() => { const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements); const _vo0 = (input, _path, _exceptionable = true) => ["string" === typeof input.reason || _report(_exceptionable, {
+                    path: _path + ".reason",
+                    expected: "string",
+                    value: input.reason
+                }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
+                    path: _path + ".userPlanningRequirements",
+                    expected: "(string | undefined)",
+                    value: input.userPlanningRequirements
+                })].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: "IAutoBeApplicationProps",
+                        value: input
+                    })) && _vo0(input, _path + "", true) || _report(true, {
+                        path: _path + "",
+                        expected: "IAutoBeApplicationProps",
+                        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 = {
+    chatgpt: {
+        model: "chatgpt",
+        options: {
+            reference: true,
+            strict: false,
+            separate: null
+        },
+        functions: [
+            {
+                name: "analyze",
+                parameters: {
+                    description: "Current Type: {@link IAutoBeApplicationProps}",
+                    type: "object",
+                    properties: {
+                        reason: {
+                            title: "The reason of the function call",
+                            description: "The reason of the function call.",
+                            type: "string"
+                        },
+                        userPlanningRequirements: {
+                            title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
+                            description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>",
+                            type: "string"
+                        }
+                    },
+                    required: [
+                        "reason"
+                    ],
+                    additionalProperties: false,
+                    $defs: {}
+                },
+                output: {
+                    description: "Current Type: {@link IAutoBeApplicationResult}",
+                    type: "object",
+                    properties: {
+                        success: {
+                            type: "boolean"
+                        }
+                    },
+                    required: [
+                        "success"
+                    ]
+                },
+                description: "Run Analyze Agent.\n\nExecutes the Analyze agent to process user requirements and generate a\nstructured specification document. This agent analyzes all conversation\nhistory between users and AI, separates business logic from technical\nrequirements, and establishes development priorities and scope.\n\n**IMPORTANT**: Only call this function when sufficient requirements have\nbeen discussed to generate a comprehensive specification. The context must\ncontain enough detail about the system's purpose, core features, data\nmodels, and business rules. If requirements are unclear or incomplete,\ncontinue gathering information through conversation instead.\n\nThe agent will automatically generate follow-up questions for any ambiguous\nrequirements and continuously refine its understanding through iterative\nconversation. When executed after other agents have generated code, it can\nalso interpret change requests in the context of existing implementations.",
+                validate: (() => { const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements); const _vo0 = (input, _path, _exceptionable = true) => ["string" === typeof input.reason || _report(_exceptionable, {
+                        path: _path + ".reason",
+                        expected: "string",
+                        value: input.reason
+                    }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
+                        path: _path + ".userPlanningRequirements",
+                        expected: "(string | undefined)",
+                        value: input.userPlanningRequirements
+                    })].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: "IAutoBeApplicationProps",
+                            value: input
+                        })) && _vo0(input, _path + "", true) || _report(true, {
+                            path: _path + "",
+                            expected: "IAutoBeApplicationProps",
+                            value: input
+                        }))(input, "$input", true);
+                        const success = 0 === errors.length;
+                        return success ? {
+                            success,
+                            data: input
+                        } : {
+                            success,
+                            errors,
+                            data: input
+                        };
+                    }
+                    return {
+                        success: true,
+                        data: input
+                    };
+                }; })()
+            },
+            {
+                name: "prisma",
+                parameters: {
+                    description: "Current Type: {@link IAutoBeApplicationProps}",
+                    type: "object",
+                    properties: {
+                        reason: {
+                            title: "The reason of the function call",
+                            description: "The reason of the function call.",
+                            type: "string"
+                        },
+                        userPlanningRequirements: {
+                            title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
+                            description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>",
+                            type: "string"
+                        }
+                    },
+                    required: [
+                        "reason"
+                    ],
+                    additionalProperties: false,
+                    $defs: {}
+                },
+                output: {
+                    description: "Current Type: {@link IAutoBeApplicationResult}",
+                    type: "object",
+                    properties: {
+                        success: {
+                            type: "boolean"
+                        }
+                    },
+                    required: [
+                        "success"
+                    ]
+                },
+                description: "Run prisma agent.\n\nExecutes the Prisma agent to generate database schema files and ERD\ndocumentation. This agent reads the requirements specification created by\nthe {@link analyze Analyze agent} and produces a complete Prisma schema with\ncomprehensive documentation for each entity and attribute.\n\n**PREREQUISITE**: Only call this function after the {@link analyze} function\nhas been successfully executed and a requirements specification document\nhas been generated. The Prisma agent depends on the structured requirements\nanalysis to design the database schema properly. Without a completed\nrequirements specification, this function should NOT be called.\n\nThe agent will automatically validate the generated schema using the Prisma\ncompiler, self-correct any compilation errors through feedback loops, and\ngenerate ERD documentation using prisma-markdown. An internal review\nprocess ensures schema quality and optimization.",
+                validate: (() => { const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements); const _vo0 = (input, _path, _exceptionable = true) => ["string" === typeof input.reason || _report(_exceptionable, {
+                        path: _path + ".reason",
+                        expected: "string",
+                        value: input.reason
+                    }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
+                        path: _path + ".userPlanningRequirements",
+                        expected: "(string | undefined)",
+                        value: input.userPlanningRequirements
+                    })].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: "IAutoBeApplicationProps",
+                            value: input
+                        })) && _vo0(input, _path + "", true) || _report(true, {
+                            path: _path + "",
+                            expected: "IAutoBeApplicationProps",
+                            value: input
+                        }))(input, "$input", true);
+                        const success = 0 === errors.length;
+                        return success ? {
+                            success,
+                            data: input
+                        } : {
+                            success,
+                            errors,
+                            data: input
+                        };
+                    }
+                    return {
+                        success: true,
+                        data: input
+                    };
+                }; })()
+            },
+            {
+                name: "interface",
+                parameters: {
+                    description: "Current Type: {@link IAutoBeApplicationProps}",
+                    type: "object",
+                    properties: {
+                        reason: {
+                            title: "The reason of the function call",
+                            description: "The reason of the function call.",
+                            type: "string"
+                        },
+                        userPlanningRequirements: {
+                            title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
+                            description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>",
+                            type: "string"
+                        }
+                    },
+                    required: [
+                        "reason"
+                    ],
+                    additionalProperties: false,
+                    $defs: {}
+                },
+                output: {
+                    description: "Current Type: {@link IAutoBeApplicationResult}",
+                    type: "object",
+                    properties: {
+                        success: {
+                            type: "boolean"
+                        }
+                    },
+                    required: [
+                        "success"
+                    ]
+                },
+                description: "Run interface agent.\n\nExecutes the Interface agent to design and generate API interfaces. This\nagent creates OpenAPI schemas and TypeScript/NestJS code based on the\nrequirements specification and ERD documentation from previous agents.\n\nThe agent follows a sophisticated pipeline: first constructing formal\nOpenAPI Operation Schemas and JSON Schemas, then validating these schemas,\nand finally transforming them into NestJS controllers and DTOs. Each\ngenerated interface includes comprehensive JSDoc comments and undergoes\ninternal review for consistency.",
+                validate: (() => { const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements); const _vo0 = (input, _path, _exceptionable = true) => ["string" === typeof input.reason || _report(_exceptionable, {
+                        path: _path + ".reason",
+                        expected: "string",
+                        value: input.reason
+                    }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
+                        path: _path + ".userPlanningRequirements",
+                        expected: "(string | undefined)",
+                        value: input.userPlanningRequirements
+                    })].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: "IAutoBeApplicationProps",
+                            value: input
+                        })) && _vo0(input, _path + "", true) || _report(true, {
+                            path: _path + "",
+                            expected: "IAutoBeApplicationProps",
+                            value: input
+                        }))(input, "$input", true);
+                        const success = 0 === errors.length;
+                        return success ? {
+                            success,
+                            data: input
+                        } : {
+                            success,
+                            errors,
+                            data: input
+                        };
+                    }
+                    return {
+                        success: true,
+                        data: input
+                    };
+                }; })()
+            },
+            {
+                name: "test",
+                parameters: {
+                    description: "Current Type: {@link IAutoBeApplicationProps}",
+                    type: "object",
+                    properties: {
+                        reason: {
+                            title: "The reason of the function call",
+                            description: "The reason of the function call.",
+                            type: "string"
+                        },
+                        userPlanningRequirements: {
+                            title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
+                            description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>",
+                            type: "string"
+                        }
+                    },
+                    required: [
+                        "reason"
+                    ],
+                    additionalProperties: false,
+                    $defs: {}
+                },
+                output: {
+                    description: "Current Type: {@link IAutoBeApplicationResult}",
+                    type: "object",
+                    properties: {
+                        success: {
+                            type: "boolean"
+                        }
+                    },
+                    required: [
+                        "success"
+                    ]
+                },
+                description: "Run test program agent.\n\nExecutes the Test agent to generate comprehensive E2E test suites for all\n{@link interface API interfaces}. This agent synthesizes outputs from\nprevious agents to create tests that validate both individual endpoints and\ntheir interactions.\n\n**PREREQUISITE**: Only call this function after the {@link interface}\nfunction has been successfully executed and API interfaces have been\ngenerated. The Test agent requires the completed API interface definitions,\nOpenAPI schemas, and TypeScript code to generate appropriate test\nscenarios. Without completed interface design, this function should NOT be\ncalled.\n\nThe agent will analyze dependency relationships between API functions,\nstructure integrated test scenarios with correct execution sequences, and\nenhance pre-generated test scaffolds with business logic validation.\nTypeScript compiler validation and internal review ensure test quality and\noptimal coverage.",
+                validate: (() => { const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements); const _vo0 = (input, _path, _exceptionable = true) => ["string" === typeof input.reason || _report(_exceptionable, {
+                        path: _path + ".reason",
+                        expected: "string",
+                        value: input.reason
+                    }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
+                        path: _path + ".userPlanningRequirements",
+                        expected: "(string | undefined)",
+                        value: input.userPlanningRequirements
+                    })].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: "IAutoBeApplicationProps",
+                            value: input
+                        })) && _vo0(input, _path + "", true) || _report(true, {
+                            path: _path + "",
+                            expected: "IAutoBeApplicationProps",
+                            value: input
+                        }))(input, "$input", true);
+                        const success = 0 === errors.length;
+                        return success ? {
+                            success,
+                            data: input
+                        } : {
+                            success,
+                            errors,
+                            data: input
+                        };
+                    }
+                    return {
+                        success: true,
+                        data: input
+                    };
+                }; })()
+            },
+            {
+                name: "realize",
+                parameters: {
+                    description: "Current Type: {@link IAutoBeApplicationProps}",
+                    type: "object",
+                    properties: {
+                        reason: {
+                            title: "The reason of the function call",
+                            description: "The reason of the function call.",
+                            type: "string"
+                        },
+                        userPlanningRequirements: {
+                            title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
+                            description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>",
+                            type: "string"
+                        }
+                    },
+                    required: [
+                        "reason"
+                    ],
+                    additionalProperties: false,
+                    $defs: {}
+                },
+                output: {
+                    description: "Current Type: {@link IAutoBeApplicationResult}",
+                    type: "object",
+                    properties: {
+                        success: {
+                            type: "boolean"
+                        }
+                    },
+                    required: [
+                        "success"
+                    ]
+                },
+                description: "Run realize agent.\n\nExecutes the Realize agent to implement the actual business logic for each\nAPI endpoint. This agent synthesizes all outputs from previous agents to\ngenerate fully functional service provider code.\n\n**PREREQUISITE**: Only call this function after the {@link interface}\nfunction has been successfully executed and API interfaces have been\ngenerated. The Realize agent requires the completed API interface\ndefinitions to implement the corresponding service logic. It also benefits\nfrom having test code available for validation. Without completed interface\ndesign, this function should NOT be called.\n\nThe agent will create service implementations with multiple validation\nlayers: TypeScript compiler feedback, runtime validation through test\nexecution, and quality optimization through internal review. The generated\ncode handles database interactions through Prisma, implements security and\nvalidation checks, and processes business rules according to\nspecifications.",
+                validate: (() => { const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements); const _vo0 = (input, _path, _exceptionable = true) => ["string" === typeof input.reason || _report(_exceptionable, {
+                        path: _path + ".reason",
+                        expected: "string",
+                        value: input.reason
+                    }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
+                        path: _path + ".userPlanningRequirements",
+                        expected: "(string | undefined)",
+                        value: input.userPlanningRequirements
+                    })].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: "IAutoBeApplicationProps",
+                            value: input
+                        })) && _vo0(input, _path + "", true) || _report(true, {
+                            path: _path + "",
+                            expected: "IAutoBeApplicationProps",
+                            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,
+    llama: claude,
+    deepseek: claude,
+    "3.1": claude,
+    "3.0": {
+        model: "3.0",
+        options: {
+            constraint: true,
+            recursive: 3,
+            separate: null
+        },
+        functions: [
+            {
+                name: "analyze",
+                parameters: {
+                    type: "object",
+                    properties: {
+                        reason: {
+                            type: "string",
+                            title: "The reason of the function call",
+                            description: "The reason of the function call."
+                        },
+                        userPlanningRequirements: {
+                            type: "string",
+                            title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
+                            description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>"
+                        }
+                    },
+                    required: [
+                        "reason"
+                    ],
+                    description: "Current Type: {@link IAutoBeApplicationProps}",
+                    additionalProperties: false
+                },
+                output: {
+                    type: "object",
+                    properties: {
+                        success: {
+                            type: "boolean"
+                        }
+                    },
+                    required: [
+                        "success"
+                    ],
+                    description: "Current Type: {@link IAutoBeApplicationResult}",
+                    additionalProperties: false
+                },
+                description: "Run Analyze Agent.\n\nExecutes the Analyze agent to process user requirements and generate a\nstructured specification document. This agent analyzes all conversation\nhistory between users and AI, separates business logic from technical\nrequirements, and establishes development priorities and scope.\n\n**IMPORTANT**: Only call this function when sufficient requirements have\nbeen discussed to generate a comprehensive specification. The context must\ncontain enough detail about the system's purpose, core features, data\nmodels, and business rules. If requirements are unclear or incomplete,\ncontinue gathering information through conversation instead.\n\nThe agent will automatically generate follow-up questions for any ambiguous\nrequirements and continuously refine its understanding through iterative\nconversation. When executed after other agents have generated code, it can\nalso interpret change requests in the context of existing implementations.",
+                validate: (() => { const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements); const _vo0 = (input, _path, _exceptionable = true) => ["string" === typeof input.reason || _report(_exceptionable, {
+                        path: _path + ".reason",
+                        expected: "string",
+                        value: input.reason
+                    }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
+                        path: _path + ".userPlanningRequirements",
+                        expected: "(string | undefined)",
+                        value: input.userPlanningRequirements
+                    })].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: "IAutoBeApplicationProps",
+                            value: input
+                        })) && _vo0(input, _path + "", true) || _report(true, {
+                            path: _path + "",
+                            expected: "IAutoBeApplicationProps",
+                            value: input
+                        }))(input, "$input", true);
+                        const success = 0 === errors.length;
+                        return success ? {
+                            success,
+                            data: input
+                        } : {
+                            success,
+                            errors,
+                            data: input
+                        };
+                    }
+                    return {
+                        success: true,
+                        data: input
+                    };
+                }; })()
+            },
+            {
+                name: "prisma",
+                parameters: {
+                    type: "object",
+                    properties: {
+                        reason: {
+                            type: "string",
+                            title: "The reason of the function call",
+                            description: "The reason of the function call."
+                        },
+                        userPlanningRequirements: {
+                            type: "string",
+                            title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
+                            description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>"
+                        }
+                    },
+                    required: [
+                        "reason"
+                    ],
+                    description: "Current Type: {@link IAutoBeApplicationProps}",
+                    additionalProperties: false
+                },
+                output: {
+                    type: "object",
+                    properties: {
+                        success: {
+                            type: "boolean"
+                        }
+                    },
+                    required: [
+                        "success"
+                    ],
+                    description: "Current Type: {@link IAutoBeApplicationResult}",
+                    additionalProperties: false
+                },
+                description: "Run prisma agent.\n\nExecutes the Prisma agent to generate database schema files and ERD\ndocumentation. This agent reads the requirements specification created by\nthe {@link analyze Analyze agent} and produces a complete Prisma schema with\ncomprehensive documentation for each entity and attribute.\n\n**PREREQUISITE**: Only call this function after the {@link analyze} function\nhas been successfully executed and a requirements specification document\nhas been generated. The Prisma agent depends on the structured requirements\nanalysis to design the database schema properly. Without a completed\nrequirements specification, this function should NOT be called.\n\nThe agent will automatically validate the generated schema using the Prisma\ncompiler, self-correct any compilation errors through feedback loops, and\ngenerate ERD documentation using prisma-markdown. An internal review\nprocess ensures schema quality and optimization.",
+                validate: (() => { const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements); const _vo0 = (input, _path, _exceptionable = true) => ["string" === typeof input.reason || _report(_exceptionable, {
+                        path: _path + ".reason",
+                        expected: "string",
+                        value: input.reason
+                    }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
+                        path: _path + ".userPlanningRequirements",
+                        expected: "(string | undefined)",
+                        value: input.userPlanningRequirements
+                    })].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: "IAutoBeApplicationProps",
+                            value: input
+                        })) && _vo0(input, _path + "", true) || _report(true, {
+                            path: _path + "",
+                            expected: "IAutoBeApplicationProps",
+                            value: input
+                        }))(input, "$input", true);
+                        const success = 0 === errors.length;
+                        return success ? {
+                            success,
+                            data: input
+                        } : {
+                            success,
+                            errors,
+                            data: input
+                        };
+                    }
+                    return {
+                        success: true,
+                        data: input
+                    };
+                }; })()
+            },
+            {
+                name: "interface",
+                parameters: {
+                    type: "object",
+                    properties: {
+                        reason: {
+                            type: "string",
+                            title: "The reason of the function call",
+                            description: "The reason of the function call."
+                        },
+                        userPlanningRequirements: {
+                            type: "string",
+                            title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
+                            description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>"
+                        }
+                    },
+                    required: [
+                        "reason"
+                    ],
+                    description: "Current Type: {@link IAutoBeApplicationProps}",
+                    additionalProperties: false
+                },
+                output: {
+                    type: "object",
+                    properties: {
+                        success: {
+                            type: "boolean"
+                        }
+                    },
+                    required: [
+                        "success"
+                    ],
+                    description: "Current Type: {@link IAutoBeApplicationResult}",
+                    additionalProperties: false
+                },
+                description: "Run interface agent.\n\nExecutes the Interface agent to design and generate API interfaces. This\nagent creates OpenAPI schemas and TypeScript/NestJS code based on the\nrequirements specification and ERD documentation from previous agents.\n\nThe agent follows a sophisticated pipeline: first constructing formal\nOpenAPI Operation Schemas and JSON Schemas, then validating these schemas,\nand finally transforming them into NestJS controllers and DTOs. Each\ngenerated interface includes comprehensive JSDoc comments and undergoes\ninternal review for consistency.",
+                validate: (() => { const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements); const _vo0 = (input, _path, _exceptionable = true) => ["string" === typeof input.reason || _report(_exceptionable, {
+                        path: _path + ".reason",
+                        expected: "string",
+                        value: input.reason
+                    }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
+                        path: _path + ".userPlanningRequirements",
+                        expected: "(string | undefined)",
+                        value: input.userPlanningRequirements
+                    })].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: "IAutoBeApplicationProps",
+                            value: input
+                        })) && _vo0(input, _path + "", true) || _report(true, {
+                            path: _path + "",
+                            expected: "IAutoBeApplicationProps",
+                            value: input
+                        }))(input, "$input", true);
+                        const success = 0 === errors.length;
+                        return success ? {
+                            success,
+                            data: input
+                        } : {
+                            success,
+                            errors,
+                            data: input
+                        };
+                    }
+                    return {
+                        success: true,
+                        data: input
+                    };
+                }; })()
+            },
+            {
+                name: "test",
+                parameters: {
+                    type: "object",
+                    properties: {
+                        reason: {
+                            type: "string",
+                            title: "The reason of the function call",
+                            description: "The reason of the function call."
+                        },
+                        userPlanningRequirements: {
+                            type: "string",
+                            title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
+                            description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>"
+                        }
+                    },
+                    required: [
+                        "reason"
+                    ],
+                    description: "Current Type: {@link IAutoBeApplicationProps}",
+                    additionalProperties: false
+                },
+                output: {
+                    type: "object",
+                    properties: {
+                        success: {
+                            type: "boolean"
+                        }
+                    },
+                    required: [
+                        "success"
+                    ],
+                    description: "Current Type: {@link IAutoBeApplicationResult}",
+                    additionalProperties: false
+                },
+                description: "Run test program agent.\n\nExecutes the Test agent to generate comprehensive E2E test suites for all\n{@link interface API interfaces}. This agent synthesizes outputs from\nprevious agents to create tests that validate both individual endpoints and\ntheir interactions.\n\n**PREREQUISITE**: Only call this function after the {@link interface}\nfunction has been successfully executed and API interfaces have been\ngenerated. The Test agent requires the completed API interface definitions,\nOpenAPI schemas, and TypeScript code to generate appropriate test\nscenarios. Without completed interface design, this function should NOT be\ncalled.\n\nThe agent will analyze dependency relationships between API functions,\nstructure integrated test scenarios with correct execution sequences, and\nenhance pre-generated test scaffolds with business logic validation.\nTypeScript compiler validation and internal review ensure test quality and\noptimal coverage.",
+                validate: (() => { const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements); const _vo0 = (input, _path, _exceptionable = true) => ["string" === typeof input.reason || _report(_exceptionable, {
+                        path: _path + ".reason",
+                        expected: "string",
+                        value: input.reason
+                    }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
+                        path: _path + ".userPlanningRequirements",
+                        expected: "(string | undefined)",
+                        value: input.userPlanningRequirements
+                    })].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: "IAutoBeApplicationProps",
+                            value: input
+                        })) && _vo0(input, _path + "", true) || _report(true, {
+                            path: _path + "",
+                            expected: "IAutoBeApplicationProps",
+                            value: input
+                        }))(input, "$input", true);
+                        const success = 0 === errors.length;
+                        return success ? {
+                            success,
+                            data: input
+                        } : {
+                            success,
+                            errors,
+                            data: input
+                        };
+                    }
+                    return {
+                        success: true,
+                        data: input
+                    };
+                }; })()
+            },
+            {
+                name: "realize",
+                parameters: {
+                    type: "object",
+                    properties: {
+                        reason: {
+                            type: "string",
+                            title: "The reason of the function call",
+                            description: "The reason of the function call."
+                        },
+                        userPlanningRequirements: {
+                            type: "string",
+                            title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
+                            description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>"
+                        }
+                    },
+                    required: [
+                        "reason"
+                    ],
+                    description: "Current Type: {@link IAutoBeApplicationProps}",
+                    additionalProperties: false
+                },
+                output: {
+                    type: "object",
+                    properties: {
+                        success: {
+                            type: "boolean"
+                        }
+                    },
+                    required: [
+                        "success"
+                    ],
+                    description: "Current Type: {@link IAutoBeApplicationResult}",
+                    additionalProperties: false
+                },
+                description: "Run realize agent.\n\nExecutes the Realize agent to implement the actual business logic for each\nAPI endpoint. This agent synthesizes all outputs from previous agents to\ngenerate fully functional service provider code.\n\n**PREREQUISITE**: Only call this function after the {@link interface}\nfunction has been successfully executed and API interfaces have been\ngenerated. The Realize agent requires the completed API interface\ndefinitions to implement the corresponding service logic. It also benefits\nfrom having test code available for validation. Without completed interface\ndesign, this function should NOT be called.\n\nThe agent will create service implementations with multiple validation\nlayers: TypeScript compiler feedback, runtime validation through test\nexecution, and quality optimization through internal review. The generated\ncode handles database interactions through Prisma, implements security and\nvalidation checks, and processes business rules according to\nspecifications.",
+                validate: (() => { const _io0 = input => "string" === typeof input.reason && (undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements); const _vo0 = (input, _path, _exceptionable = true) => ["string" === typeof input.reason || _report(_exceptionable, {
+                        path: _path + ".reason",
+                        expected: "string",
+                        value: input.reason
+                    }), undefined === input.userPlanningRequirements || "string" === typeof input.userPlanningRequirements || _report(_exceptionable, {
+                        path: _path + ".userPlanningRequirements",
+                        expected: "(string | undefined)",
+                        value: input.userPlanningRequirements
+                    })].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: "IAutoBeApplicationProps",
+                            value: input
+                        })) && _vo0(input, _path + "", true) || _report(true, {
+                            path: _path + "",
+                            expected: "IAutoBeApplicationProps",
+                            value: input
+                        }))(input, "$input", true);
+                        const success = 0 === errors.length;
+                        return success ? {
+                            success,
+                            data: input
+                        } : {
+                            success,
+                            errors,
+                            data: input
+                        };
+                    }
+                    return {
+                        success: true,
+                        data: input
+                    };
+                }; })()
+            }
+        ]
+    },
+};
+//# sourceMappingURL=createAutoBeApplication.js.map