@autobe/agent 0.5.2 → 0.7.0

package/lib/factory/createAutoBeApplication.js

@@ -49,11 +49,11 @@ 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 orchestrateAnalyze_1 = require("../orchestrate/analyze/orchestrateAnalyze");
 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 orchestrateTest_1 = require("../orchestrate/test/orchestrateTest");
 const StringUtil_1 = require("../utils/StringUtil");
 const createAutoBeController = (props) => {
     (0, assertSchemaModel_1.assertSchemaModel)(props.model);
@@ -166,7 +166,7 @@ const claude = {
                         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\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.",
+                        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"
                     }
                 },
@@ -258,7 +258,7 @@ const claude = {
                         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\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.",
+                        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"
                     }
                 },
@@ -350,7 +350,7 @@ const claude = {
                         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\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.",
+                        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"
                     }
                 },
@@ -442,7 +442,7 @@ const claude = {
                         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\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.",
+                        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"
                     }
                 },
@@ -534,7 +534,7 @@ const claude = {
                         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\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.",
+                        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"
                     }
                 },
@@ -637,7 +637,7 @@ const collection = {
                             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\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.",
+                            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"
                         }
                     },
@@ -720,7 +720,7 @@ const collection = {
                             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\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.",
+                            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"
                         }
                     },
@@ -803,7 +803,7 @@ const collection = {
                             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\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.",
+                            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"
                         }
                     },
@@ -886,7 +886,7 @@ const collection = {
                             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\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.",
+                            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"
                         }
                     },
@@ -969,7 +969,7 @@ const collection = {
                             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\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.",
+                            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"
                         }
                     },
@@ -1066,7 +1066,7 @@ const collection = {
                         },
                         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\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."
+                            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: [
@@ -1149,7 +1149,7 @@ const collection = {
                         },
                         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\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."
+                            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: [
@@ -1232,7 +1232,7 @@ const collection = {
                         },
                         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\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."
+                            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: [
@@ -1315,7 +1315,7 @@ const collection = {
                         },
                         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\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."
+                            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: [
@@ -1398,7 +1398,7 @@ const collection = {
                         },
                         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\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."
+                            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: [

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,wFAAqF;AACrF,0EAAuE;AACvE,0EAAuE;AACvE,oEAAiE;AACjE,+EAA4E;AAC5E,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"}