@autobe/agent 0.9.1 → 0.9.2

package/lib/factory/createAutoBeApplication.js

@@ -164,10 +164,6 @@ const claude = {
                         title: "The reason of the function call",
                         description: "The reason of the function call.",
                         type: "string"
-                    },
-                    userPlanningRequirements: {
-                        description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
-                        type: "string"
                     }
                 },
                 required: [
@@ -209,14 +205,10 @@ const claude = {
                 ]
             },
             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, {
+            validate: (() => { const _io0 = input => "string" === typeof input.reason; 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 = [];
@@ -256,10 +248,6 @@ const claude = {
                         title: "The reason of the function call",
                         description: "The reason of the function call.",
                         type: "string"
-                    },
-                    userPlanningRequirements: {
-                        description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
-                        type: "string"
                     }
                 },
                 required: [
@@ -301,14 +289,10 @@ const claude = {
                 ]
             },
             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, {
+            validate: (() => { const _io0 = input => "string" === typeof input.reason; 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 = [];
@@ -348,10 +332,6 @@ const claude = {
                         title: "The reason of the function call",
                         description: "The reason of the function call.",
                         type: "string"
-                    },
-                    userPlanningRequirements: {
-                        description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
-                        type: "string"
                     }
                 },
                 required: [
@@ -393,14 +373,10 @@ const claude = {
                 ]
             },
             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, {
+            validate: (() => { const _io0 = input => "string" === typeof input.reason; 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 = [];
@@ -440,10 +416,6 @@ const claude = {
                         title: "The reason of the function call",
                         description: "The reason of the function call.",
                         type: "string"
-                    },
-                    userPlanningRequirements: {
-                        description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
-                        type: "string"
                     }
                 },
                 required: [
@@ -485,14 +457,10 @@ const claude = {
                 ]
             },
             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, {
+            validate: (() => { const _io0 = input => "string" === typeof input.reason; 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 = [];
@@ -532,10 +500,6 @@ const claude = {
                         title: "The reason of the function call",
                         description: "The reason of the function call.",
                         type: "string"
-                    },
-                    userPlanningRequirements: {
-                        description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
-                        type: "string"
                     }
                 },
                 required: [
@@ -577,14 +541,10 @@ const claude = {
                 ]
             },
             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, {
+            validate: (() => { const _io0 = input => "string" === typeof input.reason; 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 = [];
@@ -635,10 +595,6 @@ const collection = {
                             title: "The reason of the function call",
                             description: "The reason of the function call.",
                             type: "string"
-                        },
-                        userPlanningRequirements: {
-                            description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
-                            type: "string"
                         }
                     },
                     required: [
@@ -671,14 +627,10 @@ const collection = {
                     ]
                 },
                 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, {
+                validate: (() => { const _io0 = input => "string" === typeof input.reason; 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 = [];
@@ -718,10 +670,6 @@ const collection = {
                             title: "The reason of the function call",
                             description: "The reason of the function call.",
                             type: "string"
-                        },
-                        userPlanningRequirements: {
-                            description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
-                            type: "string"
                         }
                     },
                     required: [
@@ -754,14 +702,10 @@ const collection = {
                     ]
                 },
                 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, {
+                validate: (() => { const _io0 = input => "string" === typeof input.reason; 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 = [];
@@ -801,10 +745,6 @@ const collection = {
                             title: "The reason of the function call",
                             description: "The reason of the function call.",
                             type: "string"
-                        },
-                        userPlanningRequirements: {
-                            description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
-                            type: "string"
                         }
                     },
                     required: [
@@ -837,14 +777,10 @@ const collection = {
                     ]
                 },
                 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, {
+                validate: (() => { const _io0 = input => "string" === typeof input.reason; 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 = [];
@@ -884,10 +820,6 @@ const collection = {
                             title: "The reason of the function call",
                             description: "The reason of the function call.",
                             type: "string"
-                        },
-                        userPlanningRequirements: {
-                            description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
-                            type: "string"
                         }
                     },
                     required: [
@@ -920,14 +852,10 @@ const collection = {
                     ]
                 },
                 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, {
+                validate: (() => { const _io0 = input => "string" === typeof input.reason; 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 = [];
@@ -967,10 +895,6 @@ const collection = {
                             title: "The reason of the function call",
                             description: "The reason of the function call.",
                             type: "string"
-                        },
-                        userPlanningRequirements: {
-                            description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
-                            type: "string"
                         }
                     },
                     required: [
@@ -1003,14 +927,10 @@ const collection = {
                     ]
                 },
                 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, {
+                validate: (() => { const _io0 = input => "string" === typeof input.reason; 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 = [];
@@ -1063,10 +983,6 @@ const collection = {
                             type: "string",
                             title: "The reason of the function call",
                             description: "The reason of the function call."
-                        },
-                        userPlanningRequirements: {
-                            type: "string",
-                            description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages."
                         }
                     },
                     required: [
@@ -1100,14 +1016,10 @@ const collection = {
                     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, {
+                validate: (() => { const _io0 = input => "string" === typeof input.reason; 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 = [];
@@ -1146,10 +1058,6 @@ const collection = {
                             type: "string",
                             title: "The reason of the function call",
                             description: "The reason of the function call."
-                        },
-                        userPlanningRequirements: {
-                            type: "string",
-                            description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages."
                         }
                     },
                     required: [
@@ -1183,14 +1091,10 @@ const collection = {
                     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, {
+                validate: (() => { const _io0 = input => "string" === typeof input.reason; 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 = [];
@@ -1229,10 +1133,6 @@ const collection = {
                             type: "string",
                             title: "The reason of the function call",
                             description: "The reason of the function call."
-                        },
-                        userPlanningRequirements: {
-                            type: "string",
-                            description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages."
                         }
                     },
                     required: [
@@ -1266,14 +1166,10 @@ const collection = {
                     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, {
+                validate: (() => { const _io0 = input => "string" === typeof input.reason; 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 = [];
@@ -1312,10 +1208,6 @@ const collection = {
                             type: "string",
                             title: "The reason of the function call",
                             description: "The reason of the function call."
-                        },
-                        userPlanningRequirements: {
-                            type: "string",
-                            description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages."
                         }
                     },
                     required: [
@@ -1349,14 +1241,10 @@ const collection = {
                     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, {
+                validate: (() => { const _io0 = input => "string" === typeof input.reason; 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 = [];
@@ -1395,10 +1283,6 @@ const collection = {
                             type: "string",
                             title: "The reason of the function call",
                             description: "The reason of the function call."
-                        },
-                        userPlanningRequirements: {
-                            type: "string",
-                            description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages."
                         }
                     },
                     required: [
@@ -1432,14 +1316,10 @@ const collection = {
                     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, {
+                validate: (() => { const _io0 = input => "string" === typeof input.reason; 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 = [];

package/lib/factory/createAutoBeApplication.js.map

@@ -1 +1 @@
-{"version":3,"file":"createAutoBeApplication.js","sourceRoot":"","sources":["../../src/factory/createAutoBeApplication.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAEA,kDAA0B;AAI1B,oEAAiE;AACjE,kFAA+E;AAC/E,wFAAqF;AACrF,0EAAuE;AACvE,+EAA4E;AAC5E,yEAAsE;AACtE,oDAAiD;AAE1C,MAAM,sBAAsB,GAAG,CAAiC,KAGtE,EAAqC,EAAE;IACtC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAC/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,CACyB,CAAC;IACvC,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,QAAQ;QACd,WAAW;QACX,OAAO,EAAE;YACP,OAAO,EAAE,CAAO,IAAI,EAAE,EAAE;gBACtB,MAAM,CAAC,GAAG,MAAM,IAAA,uCAAkB,EAAC,KAAK,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC;gBACxD,IAAI,CAAC,CAAC,IAAI,KAAK,SAAS;oBACtB,OAAO;wBACL,IAAI,EAAE,SAAS;wBACf,WAAW,EACT,iEAAiE;qBACpE,CAAC;;oBAEF,OAAO;wBACL,IAAI,EAAE,aAAa;wBACnB,WAAW,EAAE,uBAAU,CAAC,IAAI,CAAA;;;aAG3B;qBACF,CAAC;YACN,CAAC,CAAA;YACD,MAAM,EAAE,CAAO,IAAI,EAAE,EAAE;gBACrB,MAAM,CAAC,GAAG,MAAM,IAAA,qCAAiB,EAAC,KAAK,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC;gBACvD,IAAI,CAAC,CAAC,IAAI,KAAK,QAAQ;oBACrB,OAAO;wBACL,IAAI,EAAE,CAAC,CAAC,QAAQ,CAAC,IAAI;wBACrB,WAAW,EACT,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;4BAC3B,CAAC,CAAC,kDAAkD;4BACpD,CAAC,CAAC,CAAC,CAAC,MAAM,CAAC,OAAO,KAAK,KAAK,IAAI,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;gCAC3D,CAAC,CAAC,uDAAuD;gCACzD,CAAC,CAAC,4DAA4D;qBACrE,CAAC;;oBAEF,OAAO;wBACL,IAAI,EAAE,6BAA6B;wBACnC,WAAW,EAAE,4CAA4C;qBAC1D,CAAC;YACN,CAAC,CAAA;YACD,SAAS,EAAE,CAAO,IAAI,EAAE,EAAE;gBACxB,MAAM,CAAC,GAAG,MAAM,IAAA,2CAAoB,EAAC,KAAK,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC;gBAC1D,IAAI,CAAC,CAAC,IAAI,KAAK,WAAW;oBACxB,OAAO;wBACL,IAAI,EAAE,SAAS;wBACf,WAAW,EAAE,iDAAiD;qBAC/D,CAAC;;oBAEF,OAAO;wBACL,IAAI,EAAE,6BAA6B;wBACnC,WAAW,EAAE,uCAAuC;qBACrD,CAAC;YACN,CAAC,CAAA;YACD,IAAI,EAAE,CAAO,IAAI,EAAE,EAAE;gBACnB,MAAM,CAAC,GAAG,MAAM,IAAA,iCAAe,EAAC,KAAK,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC;gBACrD,IAAI,CAAC,CAAC,IAAI,KAAK,MAAM;oBACnB,OAAO;wBACL,IAAI,EAAE,CAAC,CAAC,QAAQ,CAAC,IAAI;wBACrB,WAAW,EACT,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;4BAC3B,CAAC,CAAC,kDAAkD;4BACpD,CAAC,CAAC,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;gCAC7B,CAAC,CAAC,qDAAqD;gCACvD,CAAC,CAAC,yDAAyD;qBAClE,CAAC;;oBAEF,OAAO;wBACL,IAAI,EAAE,6BAA6B;wBACnC,WAAW,EAAE,uCAAuC;qBACrD,CAAC;YACN,CAAC,CAAA;YACD,OAAO,EAAE,CAAO,IAAI,EAAE,EAAE;gBACtB,MAAM,CAAC,GAAG,MAAM,IAAA,uCAAkB,EAAC,KAAK,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC;gBACxD,IAAI,CAAC,CAAC,IAAI,KAAK,SAAS;oBACtB,OAAO;wBACL,IAAI,EAAE,CAAC,CAAC,QAAQ,CAAC,IAAI;wBACrB,WAAW,EACT,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;4BAC3B,CAAC,CAAC,4DAA4D;4BAC9D,CAAC,CAAC,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;gCAC7B,CAAC,CAAC,4DAA4D;gCAC9D,CAAC,CAAC,+DAA+D;qBACxE,CAAC;;oBAEF,OAAO;wBACL,IAAI,EAAE,6BAA6B;wBACnC,WAAW,EAAE,uCAAuC;qBACrD,CAAC;YACN,CAAC,CAAA;SAC2B;KAC/B,CAAC;AACJ,CAAC,CAAC;AAnGW,QAAA,sBAAsB,0BAmGjC;AAEF,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAIT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAIJ;IACH,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;IACb,KAAK;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAAoD;CAC1D,CAAC"}
+{"version":3,"file":"createAutoBeApplication.js","sourceRoot":"","sources":["../../src/factory/createAutoBeApplication.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAEA,kDAA0B;AAI1B,oEAAiE;AACjE,kFAA+E;AAC/E,wFAAqF;AACrF,0EAAuE;AACvE,+EAA4E;AAC5E,yEAAsE;AACtE,oDAAiD;AAE1C,MAAM,sBAAsB,GAAG,CAAiC,KAGtE,EAAqC,EAAE;IACtC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAC/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,CACyB,CAAC;IACvC,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,QAAQ;QACd,WAAW;QACX,OAAO,EAAE;YACP,OAAO,EAAE,CAAO,IAAI,EAAE,EAAE;gBACtB,MAAM,CAAC,GAAG,MAAM,IAAA,uCAAkB,EAAC,KAAK,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC;gBACxD,IAAI,CAAC,CAAC,IAAI,KAAK,SAAS;oBACtB,OAAO;wBACL,IAAI,EAAE,SAAS;wBACf,WAAW,EACT,iEAAiE;qBACpE,CAAC;;oBAEF,OAAO;wBACL,IAAI,EAAE,aAAa;wBACnB,WAAW,EAAE,uBAAU,CAAC,IAAI,CAAA;;;aAG3B;qBACF,CAAC;YACN,CAAC,CAAA;YACD,MAAM,EAAE,CAAO,IAAI,EAAE,EAAE;gBACrB,MAAM,CAAC,GAAG,MAAM,IAAA,qCAAiB,EAAC,KAAK,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC;gBACvD,IAAI,CAAC,CAAC,IAAI,KAAK,QAAQ;oBACrB,OAAO;wBACL,IAAI,EAAE,CAAC,CAAC,QAAQ,CAAC,IAAI;wBACrB,WAAW,EACT,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;4BAC3B,CAAC,CAAC,kDAAkD;4BACpD,CAAC,CAAC,CAAC,CAAC,MAAM,CAAC,OAAO,KAAK,KAAK,IAAI,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;gCAC3D,CAAC,CAAC,uDAAuD;gCACzD,CAAC,CAAC,4DAA4D;qBACrE,CAAC;;oBAEF,OAAO;wBACL,IAAI,EAAE,6BAA6B;wBACnC,WAAW,EAAE,4CAA4C;qBAC1D,CAAC;YACN,CAAC,CAAA;YACD,SAAS,EAAE,CAAO,IAAI,EAAE,EAAE;gBACxB,MAAM,CAAC,GAAG,MAAM,IAAA,2CAAoB,EAAC,KAAK,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC;gBAC1D,IAAI,CAAC,CAAC,IAAI,KAAK,WAAW;oBACxB,OAAO;wBACL,IAAI,EAAE,SAAS;wBACf,WAAW,EAAE,iDAAiD;qBAC/D,CAAC;;oBAEF,OAAO;wBACL,IAAI,EAAE,6BAA6B;wBACnC,WAAW,EAAE,uCAAuC;qBACrD,CAAC;YACN,CAAC,CAAA;YACD,IAAI,EAAE,CAAO,IAAI,EAAE,EAAE;gBACnB,MAAM,CAAC,GAAG,MAAM,IAAA,iCAAe,EAAC,KAAK,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC;gBACrD,IAAI,CAAC,CAAC,IAAI,KAAK,MAAM;oBACnB,OAAO;wBACL,IAAI,EAAE,CAAC,CAAC,QAAQ,CAAC,IAAI;wBACrB,WAAW,EACT,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;4BAC3B,CAAC,CAAC,kDAAkD;4BACpD,CAAC,CAAC,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;gCAC7B,CAAC,CAAC,qDAAqD;gCACvD,CAAC,CAAC,yDAAyD;qBAClE,CAAC;;oBAEF,OAAO;wBACL,IAAI,EAAE,6BAA6B;wBACnC,WAAW,EAAE,uCAAuC;qBACrD,CAAC;YACN,CAAC,CAAA;YACD,OAAO,EAAE,CAAO,IAAI,EAAE,EAAE;gBACtB,MAAM,CAAC,GAAG,MAAM,IAAA,uCAAkB,EAAC,KAAK,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC;gBACxD,IAAI,CAAC,CAAC,IAAI,KAAK,SAAS;oBACtB,OAAO;wBACL,IAAI,EAAE,CAAC,CAAC,QAAQ,CAAC,IAAI;wBACrB,WAAW,EACT,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;4BAC3B,CAAC,CAAC,4DAA4D;4BAC9D,CAAC,CAAC,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;gCAC7B,CAAC,CAAC,4DAA4D;gCAC9D,CAAC,CAAC,+DAA+D;qBACxE,CAAC;;oBAEF,OAAO;wBACL,IAAI,EAAE,6BAA6B;wBACnC,WAAW,EAAE,uCAAuC;qBACrD,CAAC;YACN,CAAC,CAAA;SAC2B;KAC/B,CAAC;AACJ,CAAC,CAAC;AAnGW,QAAA,sBAAsB,0BAmGjC;AAEF,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAIT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAIJ;IACH,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;IACb,KAAK;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAAoD;CAC1D,CAAC"}