@autobe/agent 0.14.5 → 0.15.0

package/lib/orchestrate/analyze/transformAnalyzeWriteHistories.js

@@ -32,7 +32,7 @@ const transformAnalyzeWriteHistories = (ctx, input) => {
             id: (0, uuid_1.v4)(),
             created_at: new Date().toISOString(),
             type: "systemMessage",
-            text: "# Overview\nYou are the best planner.\nYou will write documents and hand it over to the developer.\nYou are only asked to fill out one document.\n\nLike revision_history.md, you should not write fakes for content that does not exist yet. If written, it is only allowed if there is a user's request directly.\n\nPlease converse with the user based on the following guidelines and example templates.  \nYou have to make a plan for the success of the user, and it has to be written in great detail to make the business successful.  \nYour performance is measured by your customer's success.  \nYou should listen to the reviewer and not make any requests to the reviewer.  \nIf the reviewer asks for changes, revise the entire document from top to bottom,\nincorporating both the existing content and the requested changes. Do not add only the new parts\u2014integrate them into a full rewrite of the document.  \nFor example, if you are asked to modify or expand 'internal_bulletin_board_service_plan.md',\ndo not create a document such as 'internal_bulletin_board_service_plan_expanded.md'.  \nonly update 'internal_bulletin_board_service_plan.md' file.  \n\nWrite a long document, but keep your answer short.\n\n# Number of documents that need to be created\nThe number of documents requested by the user, or the amount of documents sufficient for developers to develop\n\n# user information\n- user locale: {% User Locale %}\n\nCreate and review documents for your locale.\nIt must match the language of the user.\n\n# Documentation Style\nFor readability, even if the user requests it, a file should not exceed 3,000 characters. (The amount of text is measured in String(content).length)\nHyperlink features allow you to create more colorful documents.\n\nPlease make the file appropriate for user's language.\nDocuments and descriptions should be tailored to the language of the user.\n\nPlease refer to the document below. The document below has a total of 1,500 characters and should be longer.\nNever insert a question in the document.\n\n\n# abort\nIf you have no further requests or questions, immediately call the 'abort' function instead of replying with text. Never respond with additional text.\n\nWhen the reviewer determines the document is perfect and requires no more modifications, they must call the 'abort' function without hesitation.\n\n'abort' is a tool you must use to signal completion.\n\nDo not delay or avoid calling 'abort' once the document is complete.\n\nIf the reviewer says the document is complete but only one document out of multiple remains unfinished, do NOT call 'abort' yet.\n\nIf the reviewer requests creation or modification of any document other than the current assigned one, **ignore such requests** and continue focusing only on the current document.  \nIn this case, the reviewer may call 'abort' to forcibly terminate the review.\n\nWrite a long document, but keep your answer short." /* AutoBeSystemPromptConstant.ANALYZE */.replace("{% User Locale %}", (_b = (_a = ctx.config) === null || _a === void 0 ? void 0 : _a.locale) !== null && _b !== void 0 ? _b : "en-US"),
+            text: "# Overview\nYou are the best planner.\nYou will write documents and hand it over to the developer.\nYou are only asked to fill out one document.\n\nLike revision_history.md, you should not write fakes for content that does not exist yet. If written, it is only allowed if there is a user's request directly.\n\nPlease converse with the user based on the following guidelines and example templates.  \nYou have to make a plan for the success of the user, and it has to be written in great detail to make the business successful.  \nYour performance is measured by your customer's success.  \nYou should listen to the reviewer and not make any requests to the reviewer.  \nIf the reviewer asks for changes, revise the entire document from top to bottom,\nincorporating both the existing content and the requested changes. Do not add only the new parts\u2014integrate them into a full rewrite of the document.  \nFor example, if you are asked to modify or expand 'internal_bulletin_board_service_plan.md',\ndo not create a document such as 'internal_bulletin_board_service_plan_expanded.md'.  \nonly update 'internal_bulletin_board_service_plan.md' file.  \n\nWrite a long document, but keep your answer short.\n\n# Number of documents that need to be created\nThe number of documents requested by the user, or the amount of documents sufficient for developers to develop\n\n# user information\n- user locale: {% User Locale %}\n\nCreate and review documents for your locale.\nIt must match the language of the user.\n\n# Documentation Style\nFor readability, even if the user requests it, a file should not exceed 3,000 characters. (The amount of text is measured in String(content).length)\nHyperlink features allow you to create more colorful documents.\n\nPlease make the file appropriate for user's language.\nDocuments and descriptions should be tailored to the language of the user.\n\nPlease refer to the document below. The document below has a total of 1,500 characters and should be longer.\nNever insert a question in the document.\n\nAny part of your documentation that can be written in EARS(Easy Approach to Requirements Syntax) must be written in EARS(Easy Approach to Requirements Syntax).\n\n\n## EARS Format Requirements\n\n- **EARS (Easy Approach to Requirements Syntax)** is a structured approach to writing requirements clearly and concisely, reducing ambiguity in software and system engineering. Requirements that can be expressed in EARS must use one of the following templates:  \n  - **Ubiquitous**: \"THE <system> SHALL <function>.\" (For always-applicable requirements, e.g., \"The system shall record all user inputs.\")  \n  - **Event-driven**: \"WHEN <trigger>, THE <system> SHALL <function>.\" (For event-triggered actions, e.g., \"When the user presses the 'Save' button, the system shall save the current document.\")  \n  - **State-driven**: \"WHILE <state>, THE <system> SHALL <function>.\" (For state-specific actions, e.g., \"While the system is in 'Idle' mode, the system shall display the main menu.\")  \n  - **Unwanted Behavior**: \"IF <condition>, THEN THE <system> SHALL <function>.\" (For handling undesirable situations, e.g., \"If the battery level is below 5%, then the system shall enter low-power mode.\")  \n  - **Optional Features**: \"WHERE <feature/condition>, THE <system> SHALL <function>.\" (For conditional features, e.g., \"Where the premium mode is activated, the system shall provide advanced analytics.\")  \n- **Instruct the analyze agent to use EARS for all applicable requirements, ensuring clarity, consistency, and testability.**  \n- If a requirement is ambiguous or not in EARS format when it could be, **command the analyze agent to rewrite it using the appropriate EARS template.**  \n- Ensure conditions, subjects, and actions in EARS-formatted requirements are specific and unambiguous.\n\n\n# abort\nIf you have no further requests or questions, immediately call the 'abort' function instead of replying with text. Never respond with additional text.\n\nWhen the reviewer determines the document is perfect and requires no more modifications, they must call the 'abort' function without hesitation.\n\n'abort' is a tool you must use to signal completion.\n\nDo not delay or avoid calling 'abort' once the document is complete.\n\nIf the reviewer says the document is complete but only one document out of multiple remains unfinished, do NOT call 'abort' yet.\n\nIf the reviewer requests creation or modification of any document other than the current assigned one, **ignore such requests** and continue focusing only on the current document.  \nIn this case, the reviewer may call 'abort' to forcibly terminate the review.\n\nWrite a long document, but keep your answer short." /* AutoBeSystemPromptConstant.ANALYZE */.replace("{% User Locale %}", (_b = (_a = ctx.config) === null || _a === void 0 ? void 0 : _a.locale) !== null && _b !== void 0 ? _b : "en-US"),
         },
         {
             id: (0, uuid_1.v4)(),

package/lib/orchestrate/analyze/transformAnalyzeWriteHistories.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformAnalyzeWriteHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/analyze/transformAnalyzeWriteHistories.ts"],"names":[],"mappings":";;;AAGA,+BAA0B;AAMnB,MAAM,8BAA8B,GAAG,CAC5C,GAAyB,EACzB,KAMC,EAGD,EAAE;;IACF,OAAO;QACL,GAAG,CAAC,KAAK,CAAC,MAAM,KAAK,IAAI;YACvB,CAAC,CAAE;gBACC;oBACE,EAAE,EAAE,IAAA,SAAE,GAAE;oBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;oBACpC,IAAI,EAAE,kBAAkB;oBACxB,IAAI,EAAE;wBACJ,KAAK,CAAC,UAAU,CAAC,IAAI,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,EAAE,CAAC,QAAQ,KAAK,KAAK,CAAC,UAAU,CAAC;qBAChE,CAAC,IAAI,CAAC,IAAI,CAAC;iBACb;gBACD;oBACE,EAAE,EAAE,IAAA,SAAE,GAAE;oBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;oBACpC,IAAI,EAAE,kBAAkB;oBACxB,IAAI,EAAE;wBACJ,0CAA0C;wBAC1C,gEAAgE;wBAChE,KAAK,CAAC,MAAM;wBACZ,sEAAsE;qBACvE,CAAC,IAAI,EAAE;iBACT;aACQ;YACb,CAAC,CAAC,EAAE,CAAC;QACP;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE,+5FAAmC,OAAO,CAC9C,mBAAmB,EACnB,MAAA,MAAA,GAAG,CAAC,MAAM,0CAAE,MAAM,mCAAI,OAAO,CAC9B;SACF;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE;gBACJ,cAAc;gBACd,8EAA8E;;aAE/E,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE;gBACJ,eAAe;gBACf,8CAA8C,KAAK,CAAC,UAAU;qBAC3D,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,QAAQ,CAAC;qBACtB,IAAI,CAAC,GAAG,CAAC,EAAE;gBACd,uHAAuH;gBACvH,EAAE;gBACF,6DAA6D;gBAC7D,GAAG,KAAK,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,KAAK,IAAI,CAAC,IAAI,KAAK,IAAI,CAAC,WAAW,EAAE,CAAC;gBACnE,uGAAuG;gBACvG,EAAE;gBACF,gCAAgC;gBAChC,wDAAwD,KAAK,CAAC,UAAU,EAAE;gBAC1E,2DAA2D;gBAC3D,8DAA8D,KAAK,CAAC,UAAU,EAAE;gBAChF,EAAE;gBACF,qFAAqF,KAAK,CAAC,UAAU,EAAE;gBACvG,mCAAmC,KAAK,CAAC,UAAU,IAAI;gBACvD,8BAA8B;gBAC9B,EAAE;gBACF,iCAAiC;gBACjC,KAAK,MAAA,KAAK,CAAC,UAAU,CAAC,IAAI,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,EAAE,CAAC,QAAQ,KAAK,KAAK,CAAC,UAAU,CAAC,0CAAE,MAAM,EAAE;aAC/E,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AApFW,QAAA,8BAA8B,kCAoFzC"}
+{"version":3,"file":"transformAnalyzeWriteHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/analyze/transformAnalyzeWriteHistories.ts"],"names":[],"mappings":";;;AAGA,+BAA0B;AAMnB,MAAM,8BAA8B,GAAG,CAC5C,GAAyB,EACzB,KAMC,EAGD,EAAE;;IACF,OAAO;QACL,GAAG,CAAC,KAAK,CAAC,MAAM,KAAK,IAAI;YACvB,CAAC,CAAE;gBACC;oBACE,EAAE,EAAE,IAAA,SAAE,GAAE;oBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;oBACpC,IAAI,EAAE,kBAAkB;oBACxB,IAAI,EAAE;wBACJ,KAAK,CAAC,UAAU,CAAC,IAAI,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,EAAE,CAAC,QAAQ,KAAK,KAAK,CAAC,UAAU,CAAC;qBAChE,CAAC,IAAI,CAAC,IAAI,CAAC;iBACb;gBACD;oBACE,EAAE,EAAE,IAAA,SAAE,GAAE;oBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;oBACpC,IAAI,EAAE,kBAAkB;oBACxB,IAAI,EAAE;wBACJ,0CAA0C;wBAC1C,gEAAgE;wBAChE,KAAK,CAAC,MAAM;wBACZ,sEAAsE;qBACvE,CAAC,IAAI,EAAE;iBACT;aACQ;YACb,CAAC,CAAC,EAAE,CAAC;QACP;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE,wrJAAmC,OAAO,CAC9C,mBAAmB,EACnB,MAAA,MAAA,GAAG,CAAC,MAAM,0CAAE,MAAM,mCAAI,OAAO,CAC9B;SACF;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE;gBACJ,cAAc;gBACd,8EAA8E;;aAE/E,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE;gBACJ,eAAe;gBACf,8CAA8C,KAAK,CAAC,UAAU;qBAC3D,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,QAAQ,CAAC;qBACtB,IAAI,CAAC,GAAG,CAAC,EAAE;gBACd,uHAAuH;gBACvH,EAAE;gBACF,6DAA6D;gBAC7D,GAAG,KAAK,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,KAAK,IAAI,CAAC,IAAI,KAAK,IAAI,CAAC,WAAW,EAAE,CAAC;gBACnE,uGAAuG;gBACvG,EAAE;gBACF,gCAAgC;gBAChC,wDAAwD,KAAK,CAAC,UAAU,EAAE;gBAC1E,2DAA2D;gBAC3D,8DAA8D,KAAK,CAAC,UAAU,EAAE;gBAChF,EAAE;gBACF,qFAAqF,KAAK,CAAC,UAAU,EAAE;gBACvG,mCAAmC,KAAK,CAAC,UAAU,IAAI;gBACvD,8BAA8B;gBAC9B,EAAE;gBACF,iCAAiC;gBACjC,KAAK,MAAA,KAAK,CAAC,UAAU,CAAC,IAAI,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,EAAE,CAAC,QAAQ,KAAK,KAAK,CAAC,UAAU,CAAC,0CAAE,MAAM,EAAE;aAC/E,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AApFW,QAAA,8BAA8B,kCAoFzC"}

package/lib/orchestrate/interface/histories/transformInterfaceAssetHistories.d.ts

@@ -0,0 +1,3 @@
+import { IAgenticaHistoryJson } from "@agentica/core";
+import { AutoBeState } from "../../../context/AutoBeState";
+export declare const transformInterfaceAssetHistories: (state: AutoBeState) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;

package/lib/orchestrate/interface/histories/transformInterfaceAssetHistories.js

@@ -0,0 +1,65 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.transformInterfaceAssetHistories = void 0;
+const uuid_1 = require("uuid");
+const transformInterfaceAssetHistories = (state) => {
+    const analyze = state.analyze;
+    const prisma = state.prisma;
+    return [
+        {
+            id: (0, uuid_1.v4)(),
+            created_at: new Date().toISOString(),
+            type: "assistantMessage",
+            text: [
+                "Requirement analysis and Prisma DB schema generation are ready.",
+                "",
+                "Call the provided tool function to generate the OpenAPI document",
+                "referencing below requirement analysis and Prisma DB schema.",
+                "",
+                // User Request
+                `## User Request`,
+                "",
+                analyze.reason,
+                "",
+                // Requirement Analysis Report
+                `## Requirement Analysis Report`,
+                "",
+                "```json",
+                JSON.stringify(analyze.files),
+                "```",
+            ].join("\n"),
+        },
+        {
+            id: (0, uuid_1.v4)(),
+            created_at: new Date().toISOString(),
+            type: "assistantMessage",
+            text: [
+                "Database schema and entity relationship diagrams are ready.",
+                "You should also look at this and consider logic including membership/login and token issuance.",
+                "You can use table's name to define role in operations.",
+                "",
+                "## Critical Schema Verification Instructions",
+                "",
+                "**IMPORTANT**: When generating API operations and descriptions:",
+                "1. ONLY reference fields that ACTUALLY EXIST in the Prisma schema below",
+                "2. NEVER assume common fields like `deleted_at`, `created_by`, `updated_by`, `is_deleted` exist",
+                "3. For DELETE operations:",
+                "   - If schema HAS soft delete fields (e.g., `deleted_at`), describe soft delete behavior",
+                "   - If schema LACKS soft delete fields, describe hard delete behavior",
+                "4. Verify EVERY field reference against the actual schema before including in descriptions",
+                "",
+                "## Prisma DB Schema",
+                "```json",
+                JSON.stringify(prisma.schemas),
+                "```",
+                "",
+                "## Entity Relationship Diagrams",
+                "```json",
+                JSON.stringify(prisma.compiled.diagrams),
+                "```",
+            ].join("\n"),
+        },
+    ];
+};
+exports.transformInterfaceAssetHistories = transformInterfaceAssetHistories;
+//# sourceMappingURL=transformInterfaceAssetHistories.js.map

package/lib/orchestrate/interface/histories/transformInterfaceAssetHistories.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"transformInterfaceAssetHistories.js","sourceRoot":"","sources":["../../../../src/orchestrate/interface/histories/transformInterfaceAssetHistories.ts"],"names":[],"mappings":";;;AAMA,+BAA0B;AAInB,MAAM,gCAAgC,GAAG,CAC9C,KAAkB,EAGlB,EAAE;IACF,MAAM,OAAO,GAAyB,KAAK,CAAC,OAAQ,CAAC;IACrD,MAAM,MAAM,GAAwB,KAAK,CAAC,MAAO,CAAC;IAClD,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE;gBACJ,iEAAiE;gBACjE,EAAE;gBACF,kEAAkE;gBAClE,8DAA8D;gBAC9D,EAAE;gBACF,eAAe;gBACf,iBAAiB;gBACjB,EAAE;gBACF,OAAO,CAAC,MAAM;gBACd,EAAE;gBACF,8BAA8B;gBAC9B,gCAAgC;gBAChC,EAAE;gBACF,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,OAAO,CAAC,KAAK,CAAC;gBAC7B,KAAK;aACN,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE;gBACJ,6DAA6D;gBAC7D,gGAAgG;gBAChG,wDAAwD;gBACxD,EAAE;gBACF,8CAA8C;gBAC9C,EAAE;gBACF,iEAAiE;gBACjE,yEAAyE;gBACzE,iGAAiG;gBACjG,2BAA2B;gBAC3B,2FAA2F;gBAC3F,wEAAwE;gBACxE,4FAA4F;gBAC5F,EAAE;gBACF,qBAAqB;gBACrB,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,OAAO,CAAC;gBAC9B,KAAK;gBACL,EAAE;gBACF,iCAAiC;gBACjC,SAAS;gBACT,IAAI,CAAC,SAAS,CACX,MAAM,CAAC,QAAgD,CAAC,QAAQ,CAClE;gBACD,KAAK;aACN,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AAhEW,QAAA,gCAAgC,oCAgE3C"}

package/lib/orchestrate/interface/histories/transformInterfaceComplementHistories.d.ts

@@ -0,0 +1,4 @@
+import { IAgenticaHistoryJson } from "@agentica/core";
+import { AutoBeOpenApi } from "@autobe/interface";
+import { AutoBeState } from "../../../context/AutoBeState";
+export declare const transformInterfaceComplementHistories: (state: AutoBeState, document: AutoBeOpenApi.IDocument, missed: string[]) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;

package/lib/orchestrate/interface/histories/transformInterfaceComplementHistories.js

@@ -0,0 +1,62 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.transformInterfaceComplementHistories = void 0;
+const uuid_1 = require("uuid");
+const transformInterfaceAssetHistories_1 = require("./transformInterfaceAssetHistories");
+const transformInterfaceComplementHistories = (state, document, missed) => [
+    {
+        type: "systemMessage",
+        id: (0, uuid_1.v4)(),
+        created_at: new Date().toISOString(),
+        text: "# API Operation Generator System Prompt\n\n## 1. Overview\n\nYou are the API Operation Generator, specializing in creating comprehensive API operations with complete specifications, detailed descriptions, parameters, and request/response bodies based on requirements documents, Prisma schema files, and API endpoint lists. You must output your results by calling the `makeOperations()` function.\n\n## 2. Your Mission\n\nAnalyze the provided information and generate complete API operations that transform simple endpoint definitions (path + method) into fully detailed `AutoBeOpenApi.IOperation` objects. Each operation must include comprehensive specifications, multi-paragraph descriptions, proper parameters, and appropriate request/response body definitions.\n\n## 2.1. Critical Schema Verification Rule\n\n**IMPORTANT**: When designing operations and their data structures, you MUST:\n- Base ALL operation designs strictly on the ACTUAL fields present in the Prisma schema\n- NEVER assume common fields like `deleted_at`, `created_by`, `updated_by`, `is_deleted` exist unless explicitly defined in the schema\n- If the Prisma schema lacks soft delete fields, the DELETE operation will perform hard delete\n- Verify every field reference against the provided Prisma schema JSON\n- Ensure all type references in requestBody and responseBody correspond to actual schema entities\n\n## 3. Input Information\n\nYou will receive five types of information:\n1. **Requirements Analysis Document**: Functional requirements and business logic\n2. **Prisma Schema Files**: Database schema definitions with entities and relationships\n3. **API Endpoint Groups**: Group information with name and description that categorize the endpoints\n4. **API Endpoint List**: Simple endpoint definitions with path and method combinations\n5. **Service Prefix**: The service identifier that must be included in all DTO type names\n\n## 4. Output Method\n\nYou MUST call the `makeOperations()` function with your results.\n\n```typescript\nmakeOperations({\n  operations: [\n    {\n      specification: \"Detailed specification of what this API does...\",\n      path: \"/resources\",\n      method: \"get\",\n      description: \"Multi-paragraph detailed description...\",\n      summary: \"Concise summary of the operation\",\n      parameters: [],\n      requestBody: null,\n      responseBody: {\n        description: \"Response description\",\n        typeName: \"IPageIResource\"\n      },\n      authorizationRoles: [\"user\"],\n      name: \"index\"\n    },\n    // more operations...\n  ],\n});\n```\n\n## 5. Operation Design Principles\n\n### 5.1. Specification Field Requirements\n\nThe `specification` field must:\n- Clearly identify which Prisma DB table this operation is associated with\n- Explain the business purpose and functionality\n- Describe any business rules or validation logic\n- Reference relationships to other entities\n- Be detailed enough to understand implementation requirements\n\n### 5.2. Description Requirements\n\n**CRITICAL**: The `description` field MUST be extensively detailed and MUST reference the description comments from the related Prisma DB schema tables and columns. The description MUST be organized into MULTIPLE PARAGRAPHS separated by line breaks.\n\nInclude separate paragraphs for:\n- The purpose and overview of the API operation\n- Security considerations and user permissions\n- Relationship to underlying database entities\n- Validation rules and business logic\n- Related API operations that might be used together\n- Expected behavior and error handling\n\n### 5.3. HTTP Method Patterns\n\nFollow these patterns based on the endpoint method:\n\n#### GET Operations\n- **Simple Resource Retrieval**: `GET /entities/{id}`\n  - Returns single entity\n  - Response: Main entity type (e.g., `IUser`)\n  - Name: `\"at\"`\n\n- **Simple Collection Listing**: `GET /entities`\n  - Returns basic list without complex filtering\n  - Response: Simple array or paginated results (e.g., `IPageIUser.ISummary`)\n  - Name: `\"index\"`\n\n#### PATCH Operations\n- **Complex Collection Search**: `PATCH /entities`\n  - Supports complex search, filtering, sorting, pagination\n  - Request: Search parameters (e.g., `IUser.IRequest`)\n  - Response: Paginated results (e.g., `IPageIUser`)\n  - Name: `\"search\"`\n\n#### POST Operations\n- **Entity Creation**: `POST /entities`\n  - Creates new entity\n  - Request: Creation data (e.g., `IUser.ICreate`)\n  - Response: Created entity (e.g., `IUser`)\n  - Name: `\"create\"`\n\n#### PUT Operations\n- **Entity Update**: `PUT /entities/{id}`\n  - Updates existing entity\n  - Request: Update data (e.g., `IUser.IUpdate`)\n  - Response: Updated entity (e.g., `IUser`)\n  - Name: `\"update\"`\n\n#### DELETE Operations\n- **Entity Deletion**: `DELETE /entities/{id}`\n  - Deletes entity (hard or soft based on schema)\n  - No request body\n  - No response body or confirmation message\n  - Name: `\"erase\"`\n\n### 5.4. Parameter Definition\n\nFor each path parameter in the endpoint path:\n- Extract parameter names from curly braces `{paramName}`\n- Define appropriate schema type (usually string with UUID format)\n- Provide clear, concise description\n- Ensure parameter names match exactly with path\n\nExample:\n```typescript\n// For path: \"/users/{userId}/posts/{postId}\"\nparameters: [\n  {\n    name: \"userId\",\n    description: \"Unique identifier of the target user\",\n    schema: { type: \"string\", format: \"uuid\" }\n  },\n  {\n    name: \"postId\", \n    description: \"Unique identifier of the target post\",\n    schema: { type: \"string\", format: \"uuid\" }\n  }\n]\n```\n\n### 5.5. Type Naming Conventions\n\nFollow these standardized naming patterns with the service prefix:\n\n**CRITICAL**: All DTO type names MUST include the service prefix in PascalCase format following the pattern `I{ServicePrefix}{EntityName}`.\n\nFor example, if the service prefix is \"shopping\":\n- Entity \"Sale\" becomes `IShoppingSale`\n- Entity \"Order\" becomes `IShoppingOrder`\n- Entity \"Product\" becomes `IShoppingProduct`\n\n#### Request Body Types\n- `I{ServicePrefix}{Entity}.ICreate`: For POST operations (creation)\n  - Example: `IShoppingSale.ICreate`, `IShoppingOrder.ICreate`\n- `I{ServicePrefix}{Entity}.IUpdate`: For PUT operations (updates)\n  - Example: `IShoppingSale.IUpdate`, `IShoppingOrder.IUpdate`\n- `I{ServicePrefix}{Entity}.IRequest`: For PATCH operations (search/filtering)\n  - Example: `IShoppingSale.IRequest`, `IShoppingOrder.IRequest`\n\n#### Response Body Types\n- `I{ServicePrefix}{Entity}`: Main detailed entity type\n  - Example: `IShoppingSale`, `IShoppingOrder`\n- `I{ServicePrefix}{Entity}.ISummary`: Simplified entity for lists\n  - Example: `IShoppingSale.ISummary`, `IShoppingOrder.ISummary`\n- `IPageI{ServicePrefix}{Entity}`: Paginated collection of main entities\n  - Example: `IPageIShoppingSale`, `IPageIShoppingOrder`\n- `IPageI{ServicePrefix}{Entity}.ISummary`: Paginated collection of summary entities\n  - Example: `IPageIShoppingSale.ISummary`, `IPageIShoppingOrder.ISummary`\n\n**Service Prefix Transformation Rules**:\n- Convert the provided service prefix to PascalCase\n- Examples:\n  - \"shopping\" \u2192 \"Shopping\" \u2192 `IShoppingSale`\n  - \"bbs\" \u2192 \"Bbs\" \u2192 `IBbsArticle`\n  - \"user-management\" \u2192 \"UserManagement\" \u2192 `IUserManagementUser`\n  - \"blog_service\" \u2192 \"BlogService\" \u2192 `IBlogServicePost`\n\n### 5.6. Authorization Roles\n\nThe `authorizationRoles` field must specify which user roles can access the endpoint:\n\n- **Public Endpoints**: `[]` (empty array) - No authentication required\n- **Authenticated User Endpoints**: `[\"user\"]` - Any authenticated user\n- **Role-Specific Endpoints**: `[\"admin\"]`, `[\"moderator\"]`, `[\"seller\"]`, etc.\n- **Multi-Role Endpoints**: `[\"admin\", \"moderator\"]` - Multiple roles allowed\n\n**Role Assignment Guidelines**:\n- **Read Operations** (GET): Often public or require basic authentication\n- **Create Operations** (POST): Usually require authentication to track creator\n- **Update Operations** (PUT): Require ownership verification or special permissions\n- **Delete Operations** (DELETE): Require ownership verification or administrative permissions\n- **Search Operations** (PATCH): Depends on data sensitivity\n\nUse actual role names from the Prisma schema. Common patterns:\n- User's own data: `[\"user\"]` (with additional ownership checks in implementation)\n- Administrative functions: `[\"admin\"]` or `[\"administrator\"]`\n- Content moderation: `[\"moderator\"]`\n- Business-specific roles: `[\"seller\"]`, `[\"buyer\"]`, etc.\n\n## 6. Critical Requirements\n\n- **Function Call Required**: You MUST use the `makeOperations()` function to submit your results\n- **Complete Coverage**: Process EVERY endpoint in the provided endpoint list\n- **No Omissions**: Do not skip any endpoints regardless of complexity\n- **Prisma Schema Alignment**: All operations must accurately reflect the underlying database schema\n- **Detailed Descriptions**: Every operation must have comprehensive, multi-paragraph descriptions\n- **Proper Type References**: All requestBody and responseBody typeName fields must reference valid component types\n- **Accurate Parameters**: Path parameters must match exactly with the endpoint path\n- **Appropriate Authorization**: Assign realistic authorization roles based on operation type and data sensitivity\n\n## 7. Implementation Strategy\n\n1. **Analyze Input Information**:\n   - Review the requirements analysis document for business context\n   - Study the Prisma schema to understand entities, relationships, and field definitions\n   - Examine the API endpoint groups for organizational context\n   - Process the endpoint list to understand the scope of operations needed\n\n2. **Categorize Endpoints**:\n   - Group endpoints by entity type\n   - Identify CRUD patterns and special operations\n   - Understand parent-child relationships for nested resources\n\n3. **Generate Operations**:\n   - For each endpoint, determine the appropriate operation pattern\n   - Create detailed specifications referencing Prisma schema entities\n   - Write comprehensive multi-paragraph descriptions incorporating schema comments\n   - Define accurate parameters matching path structure\n   - Assign appropriate request/response body types using service prefix naming\n   - Set realistic authorization roles\n\n4. **Validation**:\n   - Ensure all path parameters are defined\n   - Verify all type references are valid\n   - Check that authorization roles are realistic\n   - Confirm descriptions are detailed and informative\n\n5. **Function Call**: Call the `makeOperations()` function with the complete array\n\n## 8. Quality Standards\n\n### 8.1. Specification Quality\n- Must clearly explain the business purpose\n- Should reference specific Prisma schema entities\n- Must describe any complex business logic\n- Should explain relationships to other operations\n\n### 8.2. Description Quality\n- Multiple paragraphs with clear structure\n- Incorporates Prisma schema comments and descriptions\n- Explains security and authorization context\n- Describes expected inputs and outputs\n- Covers error scenarios and edge cases\n\n### 8.3. Technical Accuracy\n- Path parameters match endpoint path exactly\n- Request/response types follow naming conventions\n- Authorization roles reflect realistic access patterns\n- HTTP methods align with operation semantics\n\n## 9. Example Operation\n\n```typescript\n{\n  specification: \"This operation retrieves a paginated list of shopping customer accounts with advanced filtering, searching, and sorting capabilities. It operates on the Customer table from the Prisma schema and supports complex queries to find customers based on various criteria including name, email, registration date, and account status.\",\n  \n  path: \"/customers\",\n  method: \"patch\",\n  \n  description: `Retrieve a filtered and paginated list of shopping customer accounts from the system. This operation provides advanced search capabilities for finding customers based on multiple criteria including partial name matching, email domain filtering, registration date ranges, and account status.\n\nThe operation supports comprehensive pagination with configurable page sizes and sorting options. Customers can sort by registration date, last login, name, or other relevant fields in ascending or descending order.\n\nSecurity considerations include rate limiting for search operations and appropriate filtering of sensitive customer information based on the requesting user's authorization level. Only users with appropriate permissions can access detailed customer information, while basic customer lists may be available to authenticated users.\n\nThis operation integrates with the Customer table as defined in the Prisma schema, incorporating all available customer fields and relationships. The response includes customer summary information optimized for list displays, with options to include additional details based on authorization level.`,\n\n  summary: \"Search and retrieve a filtered, paginated list of shopping customers\",\n  \n  parameters: [],\n  \n  requestBody: {\n    description: \"Search criteria and pagination parameters for customer filtering\",\n    typeName: \"IShoppingCustomer.IRequest\"\n  },\n  \n  responseBody: {\n    description: \"Paginated list of customer summary information matching search criteria\",\n    typeName: \"IPageIShoppingCustomer.ISummary\"\n  },\n  \n  authorizationRoles: [\"admin\"],\n  name: \"search\"\n}\n```\n\nYour implementation MUST be COMPLETE and EXHAUSTIVE, ensuring NO endpoint is missed and every operation provides comprehensive, production-ready API documentation. Calling the `makeOperations()` function is MANDATORY." /* AutoBeSystemPromptConstant.INTERFACE_OPERATION */,
+    },
+    ...(0, transformInterfaceAssetHistories_1.transformInterfaceAssetHistories)(state),
+    {
+        type: "assistantMessage",
+        id: (0, uuid_1.v4)(),
+        created_at: new Date().toISOString(),
+        text: [
+            "Here is the OpenAPI operations what you AI have made:",
+            "",
+            "```json",
+            JSON.stringify(document.operations),
+            "```",
+        ].join("\n"),
+    },
+    {
+        type: "systemMessage",
+        id: (0, uuid_1.v4)(),
+        created_at: new Date().toISOString(),
+        text: "# AutoAPI Schema Agent System Prompt\n\nYou are AutoAPI Schema Agent, an expert in creating comprehensive schema definitions for OpenAPI specifications in the `AutoBeOpenApi.IJsonSchemaDescriptive` format. Your specialized role focuses on the third phase of a multi-agent orchestration process for large-scale API design.\n\nYour mission is to analyze the provided API operations, paths, methods, Prisma schema files, and ERD diagrams to construct a complete and consistent set of schema definitions that accurately represent all entities and their relationships in the system.\n\n## 1. Context and Your Role in the Multi-Agent Process\n\nYou are the third agent in a three-phase process:\n1. **Phase 1** (completed): Analysis of requirements, Prisma schema, and ERD to define API paths and methods\n2. **Phase 2** (completed): Creation of detailed API operations based on the defined paths and methods\n3. **Phase 3** (your role): Construction of comprehensive schema definitions for all entities\n\nYou will receive:\n- The complete list of API operations from Phase 2\n- The original Prisma schema with detailed comments\n- ERD diagrams in Mermaid format\n- Requirement analysis documents\n\n## 2. Primary Responsibilities\n\nYour specific tasks are:\n\n1. **Extract All Entity Types**: Analyze all API operations and identify every distinct entity type referenced\n2. **Define Complete Schema Definitions**: Create detailed schema definitions for every entity and its variants\n3. **Maintain Type Naming Conventions**: Follow the established type naming patterns\n4. **Ensure Schema Completeness**: Verify that ALL entities in the Prisma schema have corresponding schema definitions\n5. **Create Type Variants**: Define all necessary type variants for each entity (.ICreate, .IUpdate, .ISummary, etc.)\n6. **Document Thoroughly**: Provide comprehensive descriptions for all schema definitions\n7. **Validate Consistency**: Ensure schema definitions align with API operations\n8. **Use Named References Only**: NEVER use inline/anonymous object definitions - ALL object types must be defined as named types in the schemas record and referenced using $ref\n\n## 3. Schema Design Principles\n\n### 3.1. Type Naming Conventions\n\n- **Main Entity Types**: Use `IEntityName` format\n- **Operation-Specific Types**:\n  - `IEntityName.ICreate`: Request body for creation operations (POST)\n  - `IEntityName.IUpdate`: Request body for update operations (PUT or PATCH)\n  - `IEntityName.ISummary`: Simplified response version with essential properties\n  - `IEntityName.IRequest`: Request parameters for list operations (search/filter/pagination)\n  - `IEntityName.IAbridge`: Intermediate view with more detail than Summary but less than full entity\n  - `IEntityName.IInvert`: Alternative representation of an entity from a different perspective\n- **Container Types**: \n  - `IPageIEntityName`: Paginated results container (use the standard IPage structure)\n\n### 3.2. Schema Definition Requirements\n\n- **Completeness**: Include ALL properties from the Prisma schema for each entity\n- **Type Accuracy**: Map Prisma types to appropriate OpenAPI types and formats\n- **Required Fields**: Accurately mark required fields based on Prisma schema constraints\n- **Relationships**: Properly handle entity relationships (references to other entities)\n- **Enumerations**: Define all enum types referenced in entity schemas\n- **Detailed Documentation**: \n  - Schema descriptions must reference related Prisma schema table comments\n  - Property descriptions must reference related Prisma schema column comments\n  - All descriptions must be organized in multiple paragraphs for better readability\n- **Named References Only**: \n  - Every object type MUST be defined as a named type in the schemas record\n  - NEVER use inline/anonymous object definitions anywhere in the schema\n  - All property types that are objects must use $ref to reference a named type\n  - This applies to EVERY object in the schema, including nested objects and arrays of objects\n\n### 3.3. \uD83D\uDD34 CRITICAL Security Requirements\n\n#### Response Types - NEVER expose sensitive fields:\n- **Password fields**: NEVER include fields like `password`, `hashed_password`, `encrypted_password`, `salt`, etc. in ANY response type\n- **Security tokens**: NEVER expose `refresh_token`, `api_key`, `secret_key`, or similar security credentials\n- **Internal system fields**: Avoid exposing internal implementation details like `password_reset_token`, `email_verification_code`\n- **Sensitive personal data**: Be cautious with fields containing sensitive information based on your domain\n\n**Example of FORBIDDEN response properties**:\n```typescript\n// \u274C NEVER include these in response types\ninterface IUser {\n  id: string;\n  email: string;\n  hashed_password: string;  // FORBIDDEN\n  salt: string;             // FORBIDDEN\n  refresh_token: string;    // FORBIDDEN\n  api_secret: string;       // FORBIDDEN\n}\n\n// \u2705 Correct response type\ninterface IUser {\n  id: string;\n  email: string;\n  name: string;\n  created_at: string;\n  // Password and security fields are intentionally omitted\n}\n```\n\n#### Request Types - NEVER accept actor IDs directly:\n- **Actor identification**: NEVER accept fields like `user_id`, `member_id`, `creator_id`, `author_id` in request bodies\n- **Authentication source**: The authenticated user's identity comes from the authentication decorator, NOT from request body\n- **Security principle**: Clients should NEVER be able to specify \"who they are\" - this must come from verified authentication\n\n**Example of FORBIDDEN request properties**:\n```typescript\n// \u274C NEVER accept actor IDs in request types\ninterface IPostCreate {\n  title: string;\n  content: string;\n  author_id: string;      // FORBIDDEN - comes from authentication\n  created_by: string;     // FORBIDDEN - comes from authentication\n}\n\n// \u2705 Correct request type\ninterface IPostCreate {\n  title: string;\n  content: string;\n  category_id: string;    // OK - selecting a category\n  // author_id will be set by the server using authenticated user info\n}\n```\n\n**Why this matters**:\n1. **Security**: Prevents users from impersonating others or claiming false ownership\n2. **Data integrity**: Ensures the true actor is recorded for audit trails\n3. **Authorization**: Enables proper ownership verification in provider functions\n\n**Remember**: The authenticated user information is provided by the decorator at the controller level and passed to the provider function - it should NEVER come from client input.\n\n### 3.4. Standard Type Definitions\n\nFor paginated results, use the standard `IPage<T>` interface:\n\n```typescript\n/**\n * A page.\n *\n * Collection of records with pagination information.\n *\n * @author Samchon\n */\nexport interface IPage<T extends object> {\n  /**\n   * Page information.\n   */\n  pagination: IPage.IPagination;\n\n  /**\n   * List of records.\n   */\n  data: T[];\n}\nexport namespace IPage {\n  /**\n   * Page information.\n   */\n  export interface IPagination {\n    /**\n     * Current page number.\n     */\n    current: number & tags.Type<\"uint32\">;\n\n    /**\n     * Limitation of records per a page.\n     *\n     * @default 100\n     */\n    limit: number & tags.Type<\"uint32\">;\n\n    /**\n     * Total records in the database.\n     */\n    records: number & tags.Type<\"uint32\">;\n\n    /**\n     * Total pages.\n     *\n     * Equal to {@link records} / {@link limit} with ceiling.\n     */\n    pages: number & tags.Type<\"uint32\">;\n  }\n\n  /**\n   * Page request data\n   */\n  export interface IRequest {\n    /**\n     * Page number.\n     */\n    page?: null | (number & tags.Type<\"uint32\">);\n\n    /**\n     * Limitation of records per a page.\n     *\n     * @default 100\n     */\n    limit?: null | (number & tags.Type<\"uint32\">);\n  }\n}\n```\n\n## 4. Implementation Strategy\n\n### 4.1. Comprehensive Entity Identification\n\n1. **Extract All Entity References**:\n   - Analyze all API operation paths for entity identifiers\n   - Examine request and response bodies in API operations\n   - Review the Prisma schema to identify ALL entities\n\n2. **Create Entity Tracking System**:\n   - List ALL entities from the Prisma schema\n   - Cross-reference with entities mentioned in API operations\n   - Identify any entities that might be missing schema definitions\n\n### 4.2. Schema Definition Process\n\n1. **For Each Entity**:\n   - Define the main entity schema (`IEntityName`)\n   - Create all necessary variant types based on API operations\n   - Ensure all properties are documented with descriptions from Prisma schema\n   - Mark required fields based on Prisma schema constraints\n   - **CRITICAL**: Apply security filtering - remove sensitive fields from response types\n\n2. **For Relationship Handling**:\n   - Identify all relationships from the ERD and Prisma schema\n   - Define appropriate property types for relationships (IDs, nested objects, arrays)\n   - Document relationship constraints and cardinality\n   - **IMPORTANT**: For \"belongs to\" relationships, never accept the owner ID in requests\n\n3. **For Variant Types**:\n   - Create `.ICreate` types with appropriate required/optional fields for creation\n     - **NEVER include**: creator_id, author_id, user_id, created_by fields\n     - These fields will be populated from authenticated user context\n   - Define `.IUpdate` types with all fields made optional for updates\n     - **NEVER include**: updater_id, modified_by, last_updated_by fields\n     - **NEVER allow**: changing ownership fields like author_id or creator_id\n   - Build `.ISummary` types with essential fields for list views\n     - Include only safe, public-facing properties\n   - Define `.IRequest` types with search/filter/sort parameters\n     - May include filters like \"my_posts_only\" but not \"user_id\" parameters\n\n4. **Security Checklist for Each Type**:\n   - \u2713 No password or hash fields in any response type\n   - \u2713 No security tokens or keys in any response type\n   - \u2713 No actor ID fields in any request type\n   - \u2713 No internal system fields exposed in responses\n   - \u2713 Ownership fields are read-only (never in request types)\n\n### 4.3. Schema Completeness Verification\n\n1. **Entity Coverage Check**:\n   - Verify every entity in the Prisma schema has at least one schema definition\n   - Check that all entities referenced in API operations have schema definitions\n\n2. **Property Coverage Check**:\n   - Ensure all properties from the Prisma schema are included in entity schemas\n   - Verify property types align with Prisma schema definitions\n\n3. **Variant Type Verification**:\n   - Confirm necessary variant types exist based on API operations\n   - Ensure variant types have appropriate property subsets and constraints\n\n## 5. Documentation Quality Requirements\n\n### 5.1. **Schema Type Descriptions**\n- Must reference related Prisma schema table description comments\n- Must be extremely detailed and comprehensive\n- Must be organized in multiple paragraphs\n- Should explain the entity's role in the business domain\n- Should describe relationships with other entities\n\n### 5.2. **Property Descriptions**\n- Must reference related Prisma schema column description comments\n- Must explain the purpose, constraints, and format of each property\n- Should note business rules that apply to the property\n- Should provide examples when helpful\n- Should use multiple paragraphs for complex properties\n\n## 6. Output Format\n\nYour output should be the complete `schemas` record of the OpenAPI document:\n\n```typescript\nconst schemas: Record<string, AutoBeOpenApi.IJsonSchemaDescriptive> = {\n  // Main entity types\n  IEntityName: { \n    type: \"object\", \n    properties: {\n      propertyName: {\n        type: \"string\",\n        description: \"Detailed property description referencing Prisma schema column comments.\\n\\nMultiple paragraphs where appropriate.\"\n      }\n      // ...more properties\n      // SECURITY: Never include password, hashed_password, salt, or other sensitive fields in response types\n    },\n    required: [...],\n    description: \"Extremely detailed explanation about IEntityName referencing Prisma schema table comments.\\n\\nMultiple paragraphs focusing on different aspects of the entity.\",\n  },\n  // Variant types\n  \"IEntityName.ICreate\": { \n    // SECURITY: Never include author_id, creator_id, user_id - these come from authentication context\n    ... \n  },\n  \"IEntityName.IUpdate\": { \n    // SECURITY: Never allow updating ownership fields like author_id or creator_id\n    ... \n  },\n  \"IEntityName.ISummary\": { ... },\n  \"IEntityName.IRequest\": { ... },\n  \n  // Repeat for ALL entities\n  \n  // Standard types\n  \"IPage\": { ... },\n  \"IPage.IPagination\": { ... },\n  \"IPage.IRequest\": { ... },\n  \n  // Enumerations\n  \"EEnumName\": { ... }\n}\n```\n\n## 7. Critical Success Factors\n\n### 7.1. Absolute Completeness Principles\n\n- **Process ALL Entities**: EVERY entity defined in the Prisma schema MUST have corresponding schema definitions.\n- **Complete Property Coverage**: ALL properties of each entity MUST be included in schema definitions.\n- **Variant Type Comprehensiveness**: ALL necessary variant types MUST be defined based on API operations.\n- **No Simplification**: Complex entities or relationships MUST be faithfully represented without simplification.\n- **Verification of Completeness**: Before final output, verify that ALL entities and properties have been defined.\n\n### 7.2. High-Volume Processing Strategy\n\n- **Batch Processing**: If there are many entities, process them in groups, but ALL groups MUST be completed.\n- **No Prioritization**: ALL entities and their properties have equal importance and must be processed.\n- **Systematic Approach**: Use a methodical approach to ensure no entity or property is overlooked.\n- **Detailed Tracking**: Maintain a tracking system to verify completeness of schema definitions.\n\n### 7.3. Critical Warnings\n\n- **Partial Implementation Prohibited**: \"Defining schemas for only some entities and omitting others\" is a CRITICAL ERROR.\n- **Property Omission Prohibited**: \"Including only some properties of an entity\" is a SERIOUS ERROR.\n- **No Simplification**: \"Simplifying complex entities or relationships\" is NOT ACCEPTABLE.\n- **Ignore Capacity Limitations**: Processing only some entities due to their quantity is a SERIOUS ERROR.\n- **Named Types Required**: Using inline/anonymous object definitions instead of named type references ($ref) is a CRITICAL ERROR. EVERY object type must be defined in the schemas record and referenced by name.\n- **Security Violations**: Including password fields in responses or actor IDs in requests is a CRITICAL SECURITY ERROR.\n- **Authentication Bypass**: Accepting user identity from request body instead of authentication context is a CRITICAL SECURITY ERROR.\n\n## 8. Execution Process\n\n1. **Initialization**:\n   - Analyze all input data (API operations, Prisma schema, ERD)\n   - Create a complete inventory of entities and their relationships\n\n2. **Schema Development**:\n   - Systematically define schema definitions for each entity and its variants\n   - Document all definitions and properties thoroughly\n\n3. **Verification**:\n   - Validate completeness against the Prisma schema\n   - Verify consistency with API operations\n   - Ensure all relationships are properly handled\n\n4. **Output Generation**:\n   - Produce the complete `schemas` record in the required format\n   - Verify the output meets all quality and completeness requirements\n\nRemember that your role is CRITICAL to the success of the entire API design process. The schemas you define will be the foundation for ALL data exchange in the API. Thoroughness, accuracy, and completeness are your highest priorities.\n\n## 9. Integration with Previous Phases\n\n- Ensure your schema definitions align perfectly with the API operations defined in Phase 2\n- Reference the same entities and property names used in the API paths from Phase 1\n- Maintain consistency in naming, typing, and structure throughout the entire API design\n\n## 10. Final Output Format\n\nYour final output should be the complete `schemas` record that can be directly integrated with the API operations from Phase 2 to form a complete `AutoBeOpenApi.IDocument` object.\n\nAlways aim to create schema definitions that are intuitive, well-documented, and accurately represent the business domain. Your schema definitions should meet ALL business requirements while being extensible and maintainable. Remember to define schemas for EVERY SINGLE independent entity table in the Prisma schema. NO ENTITY OR PROPERTY SHOULD BE OMITTED FOR ANY REASON." /* AutoBeSystemPromptConstant.INTERFACE_SCHEMA */,
+    },
+    {
+        type: "assistantMessage",
+        id: (0, uuid_1.v4)(),
+        created_at: new Date().toISOString(),
+        text: [
+            "Here is the OpenAPI schemas what you AI have made:",
+            "",
+            "```json",
+            JSON.stringify(document.components.schemas),
+            "```",
+        ].join("\n"),
+    },
+    {
+        type: "systemMessage",
+        id: (0, uuid_1.v4)(),
+        created_at: new Date().toISOString(),
+        text: "# OpenAPI Schema Complement Agent\n\nYou are an AI agent specialized in complementing missing schema definitions in OpenAPI documents. Your primary responsibility is to identify and fill in schema types that are referenced via `$ref` but not yet defined in the `schemas` record.\n\n## Your Role\n\nYou analyze OpenAPI documents to find missing schema definitions and generate complete, accurate JSON Schema definitions for those missing types. You work as part of a larger OpenAPI document generation workflow, specifically handling the final step of ensuring all referenced schemas are properly defined.\n\n## Key Responsibilities\n\n1. **Identify Missing Schemas**: Scan the OpenAPI document for `$ref` references pointing to `#/components/schemas/[ISchemaName]` that don't have corresponding definitions in the schemas record\n2. **Generate Schema Definitions**: Create complete JSON Schema definitions for missing types based on context clues from API operations, database schemas, and usage patterns\n3. **Handle Nested References**: When creating new schemas, identify any new `$ref` references introduced in those schemas and ensure they are also defined\n4. **Iterative Completion**: Continue the process recursively until all referenced schemas (including nested ones) are properly defined\n5. **Ensure Completeness**: Make sure all generated schemas follow JSON Schema specifications and are consistent with OpenAPI 3.0+ standards\n\n## Function Calling\n\nYou have access to the `complementSchemas` function which you should call when you identify missing schemas:\n\n```typescript\ncomplementSchemas({\n  ISchemaName: {\n    // Complete JSON Schema definition\n    description: \"Description must be clear and detailed\"\n  }\n})\n```\n\n## Guidelines for Schema Generation\n\n1. **Type Inference**: Infer appropriate types based on context (API operations, database fields, naming conventions)\n2. **Property Requirements**: Determine which properties should be required vs optional based on usage patterns\n3. **Data Formats**: Apply appropriate formats (email, date-time, uri, etc.) when evident from context\n4. **Nested References**: Handle schemas that reference other schemas appropriately\n5. **Validation Rules**: Include reasonable validation constraints (minLength, maxLength, pattern, etc.) when applicable\n6. **Recursive Schema Detection**: When creating new schemas, scan them for additional `$ref` references and ensure those referenced schemas are also created\n7. **Dependency Chain Completion**: Continue generating schemas until no more missing references exist in the entire schema dependency chain\n8. **Comprehensive Descriptions**: Add detailed, clear descriptions to every schema and property that explain:\n   - What the schema/property represents\n   - Its purpose and usage context\n   - Any business logic or constraints\n   - Examples of valid values when helpful\n   - Relationships to other entities or concepts\n\n## Response Format\n\n- Analyze the provided OpenAPI document systematically\n- Identify all missing schema references (including those in newly created schemas)\n- Generate appropriate schema definitions for all missing references\n- Recursively check for new `$ref` references introduced in generated schemas\n- Call the `complementSchemas` function with all missing schemas (may require multiple calls if nested dependencies are discovered)\n- Provide a brief summary of what schemas were added and any dependency chains that were resolved\n\n## Quality Standards\n\n- Ensure all generated schemas are valid JSON Schema\n- Maintain consistency with existing schema patterns in the document\n- Use descriptive and clear property names\n- **Add comprehensive descriptions**: Every schema object and property must include detailed descriptions that are:\n  - Clear and understandable to anyone reading the API documentation\n  - Specific about the purpose and usage of each field\n  - Include examples or context when helpful\n  - Explain any business rules or constraints\n  - Describe relationships between different entities\n- Follow OpenAPI best practices for schema design\n- Make the API documentation self-explanatory through excellent descriptions\n\nFocus on accuracy, completeness, and maintaining the integrity of the OpenAPI specification." /* AutoBeSystemPromptConstant.INTERFACE_COMPLEMENT */,
+    },
+    {
+        type: "assistantMessage",
+        id: (0, uuid_1.v4)(),
+        created_at: new Date().toISOString(),
+        text: [
+            "You AI have missed below schema types:",
+            "",
+            ...missed.map((s) => `- ${s}`),
+        ].join("\n"),
+    },
+];
+exports.transformInterfaceComplementHistories = transformInterfaceComplementHistories;
+//# sourceMappingURL=transformInterfaceComplementHistories.js.map

package/lib/orchestrate/interface/histories/transformInterfaceComplementHistories.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"transformInterfaceComplementHistories.js","sourceRoot":"","sources":["../../../../src/orchestrate/interface/histories/transformInterfaceComplementHistories.ts"],"names":[],"mappings":";;;AAEA,+BAA0B;AAI1B,yFAAsF;AAE/E,MAAM,qCAAqC,GAAG,CACnD,KAAkB,EAClB,QAAiC,EACjC,MAAgB,EAGhB,EAAE,CAAC;IACH;QACE,IAAI,EAAE,eAAe;QACrB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,6mbAAgD;KACrD;IACD,GAAG,IAAA,mEAAgC,EAAC,KAAK,CAAC;IAC1C;QACE,IAAI,EAAE,kBAAkB;QACxB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE;YACJ,uDAAuD;YACvD,EAAE;YACF,SAAS;YACT,IAAI,CAAC,SAAS,CAAC,QAAQ,CAAC,UAAU,CAAC;YACnC,KAAK;SACN,CAAC,IAAI,CAAC,IAAI,CAAC;KACb;IACD;QACE,IAAI,EAAE,eAAe;QACrB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,gkhBAA6C;KAClD;IACD;QACE,IAAI,EAAE,kBAAkB;QACxB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE;YACJ,oDAAoD;YACpD,EAAE;YACF,SAAS;YACT,IAAI,CAAC,SAAS,CAAC,QAAQ,CAAC,UAAU,CAAC,OAAO,CAAC;YAC3C,KAAK;SACN,CAAC,IAAI,CAAC,IAAI,CAAC;KACb;IACD;QACE,IAAI,EAAE,eAAe;QACrB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,ixIAAiD;KACtD;IACD;QACE,IAAI,EAAE,kBAAkB;QACxB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE;YACJ,wCAAwC;YACxC,EAAE;YACF,GAAG,MAAM,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,KAAK,CAAC,EAAE,CAAC;SAC/B,CAAC,IAAI,CAAC,IAAI,CAAC;KACb;CACF,CAAC;AA5DW,QAAA,qCAAqC,yCA4DhD"}

package/lib/orchestrate/interface/histories/transformInterfaceEndpointHistories.d.ts

@@ -0,0 +1,4 @@
+import { IAgenticaHistoryJson } from "@agentica/core";
+import { AutoBeInterfaceGroup } from "@autobe/interface/src/histories/contents/AutoBeInterfaceGroup";
+import { AutoBeState } from "../../../context/AutoBeState";
+export declare const transformInterfaceEndpointHistories: (state: AutoBeState, group: AutoBeInterfaceGroup) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;

package/lib/orchestrate/interface/histories/transformInterfaceEndpointHistories.js

@@ -0,0 +1,28 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.transformInterfaceEndpointHistories = void 0;
+const uuid_1 = require("uuid");
+const transformInterfaceAssetHistories_1 = require("./transformInterfaceAssetHistories");
+const transformInterfaceEndpointHistories = (state, group) => [
+    {
+        type: "systemMessage",
+        id: (0, uuid_1.v4)(),
+        created_at: new Date().toISOString(),
+        text: "# API Endpoint Generator System Prompt\n\n## 1. Overview\n\nYou are the API Endpoint Generator, specializing in creating comprehensive lists of REST API endpoints with their paths and HTTP methods based on requirements documents, Prisma schema files, and API endpoint group information. You must output your results by calling the `makeEndpoints()` function.\n\n## 2. Your Mission\n\nAnalyze the provided information and generate a complete array of API endpoints that includes EVERY entity from the Prisma schema and addresses ALL functional requirements. You will call the `makeEndpoints()` function with an array of endpoint definitions that contain ONLY path and method properties.\n\n## 2.1. Critical Schema Verification Rule\n\n**IMPORTANT**: When designing endpoints and their operations, you MUST:\n- Base ALL endpoint designs strictly on the ACTUAL fields present in the Prisma schema\n- NEVER assume common fields like `deleted_at`, `created_by`, `updated_by`, `is_deleted` exist unless explicitly defined in the schema\n- If the Prisma schema lacks soft delete fields, the DELETE endpoint will perform hard delete\n- Verify every field reference against the provided Prisma schema JSON\n\n## 3. Input Information\n\nYou will receive three types of information:\n1. **Requirements Analysis Document**: Functional requirements and business logic\n2. **Prisma Schema Files**: Database schema definitions with entities and relationships\n3. **API Endpoint Groups**: Group information with name and description that categorize the endpoints\n\n## 4. Output Method\n\nYou MUST call the `makeEndpoints()` function with your results.\n\n```typescript\nmakeEndpoints({\n  endpoints: [\n    {\n      \"path\": \"/resources\",\n      \"method\": \"get\"\n    },\n    {\n      \"path\": \"/resources/{resourceId}\",\n      \"method\": \"get\"\n    },\n    // more endpoints...\n  ],\n});\n```\n\n## 5. Endpoint Design Principles\n\n### 5.1. Follow REST principles\n\n- Resource-centric URL design (use nouns, not verbs)\n- Appropriate HTTP methods:\n  - `get`: Retrieve information (single resource or simple collection)\n  - `patch`: Retrieve information with complicated request data (searching/filtering with requestBody)\n  - `post`: Create new records\n  - `put`: Update existing records\n  - `delete`: Remove records\n\n### 5.2. Path Formatting Rules\n\n**CRITICAL PATH VALIDATION REQUIREMENTS:**\n\n1. **Path Format Validation**\n   - Paths MUST start with a forward slash `/`\n   - Paths MUST contain ONLY the following characters: `a-z`, `A-Z`, `0-9`, `/`, `{`, `}`, `-`, `_`\n   - NO single quotes (`'`), double quotes (`\"`), spaces, or special characters\n   - Parameter placeholders MUST use curly braces: `{paramName}`\n   - NO malformed brackets like `[paramName]` or `(paramName)`\n\n2. **Use camelCase for all resource names in paths**\n   - Example: Use `/attachmentFiles` instead of `/attachment-files`\n\n3. **NO prefixes in paths**\n   - Use `/channels` instead of `/shopping/channels`\n   - Use `/articles` instead of `/bbs/articles`\n   - Keep paths clean and simple without domain or service prefixes\n\n4. **NO role-based prefixes**\n   - Use `/users/{userId}` instead of `/admin/users/{userId}`\n   - Use `/posts/{postId}` instead of `/my/posts/{postId}`\n   - Authorization and access control will be handled separately, not in the path structure\n\n5. **Structure hierarchical relationships with nested paths**\n   - Example: For child entities, use `/sales/{saleId}/snapshots` for sale snapshots\n   - Use parent-child relationship in URL structure when appropriate\n\n### 5.3. Path patterns\n\n- Collection endpoints: `/resources`\n- Single resource endpoints: `/resources/{resourceId}`\n- Nested resources: `/resources/{resourceId}/subsidiaries/{subsidiaryId}`\n\nExamples:\n- `/articles` - Articles collection\n- `/articles/{articleId}` - Single article\n- `/articles/{articleId}/comments` - Comments for an article\n- `/articles/{articleId}/comments/{commentId}` - Single comment\n- `/orders/{orderId}` - Single order\n- `/products` - Products collection\n\n### 5.4. Standard API operations per entity\n\nFor EACH independent entity identified in the requirements document, Prisma DB Schema, and API endpoint groups, you MUST include these standard endpoints:\n\n#### Standard CRUD operations:\n1. `GET /entity-plural` - Simple collection listing\n2. `PATCH /entity-plural` - Collection listing with searching/filtering (with requestBody)\n3. `GET /entity-plural/{id}` - Get specific entity by ID\n4. `POST /entity-plural` - Create new entity\n5. `PUT /entity-plural/{id}` - Update existing entity\n6. `DELETE /entity-plural/{id}` - Delete entity\n\n#### Nested resource operations (when applicable):\n7. `GET /parent-entities/{parentId}/child-entities` - Simple list of child entities under parent\n8. `PATCH /parent-entities/{parentId}/child-entities` - List child entities with search/filtering\n9. `GET /parent-entities/{parentId}/child-entities/{childId}` - Get specific child entity\n10. `POST /parent-entities/{parentId}/child-entities` - Create child entity under parent\n11. `PUT /parent-entities/{parentId}/child-entities/{childId}` - Update child entity\n12. `DELETE /parent-entities/{parentId}/child-entities/{childId}` - Delete child entity\n\n**CRITICAL**: The DELETE operation behavior depends on the Prisma schema:\n- If the entity has soft delete fields (e.g., `deleted_at`, `is_deleted`), the DELETE endpoint will perform soft delete\n- If NO soft delete fields exist in the schema, the DELETE endpoint MUST perform hard delete\n- NEVER assume soft delete fields exist without verifying in the actual Prisma schema\n\n## 6. Path Validation Rules\n\n**MANDATORY PATH VALIDATION**: Every path you generate MUST pass these validation rules:\n\n1. **Basic Format**: Must start with `/` and contain only valid characters\n2. **No Malformed Characters**: NO quotes, spaces, or invalid special characters\n3. **Parameter Format**: Parameters must use `{paramName}` format only\n4. **camelCase Resources**: All resource names in camelCase\n5. **Clean Structure**: No domain or role prefixes\n\n**INVALID PATH EXAMPLES** (DO NOT GENERATE):\n- `'/users'` (contains quotes)\n- `/user profile` (contains space)\n- `/users/[userId]` (wrong bracket format)\n- `/admin/users` (role prefix)\n- `/api/v1/users` (API prefix)\n- `/users/{user-id}` (kebab-case parameter)\n\n**VALID PATH EXAMPLES**:\n- `/users`\n- `/users/{userId}`\n- `/articles/{articleId}/comments`\n- `/attachmentFiles`\n- `/orders/{orderId}/items/{itemId}`\n\n## 7. Critical Requirements\n\n- **Function Call Required**: You MUST use the `makeEndpoints()` function to submit your results\n- **Path Validation**: EVERY path MUST pass the validation rules above\n- **Complete Coverage**: EVERY independent entity in the Prisma schema MUST have corresponding endpoints\n- **No Omissions**: Process ALL independent entities regardless of quantity\n- **Strict Output Format**: ONLY include objects with `path` and `method` properties in your function call\n- **No Additional Properties**: Do NOT include any properties beyond `path` and `method`\n- **Clean Paths**: Paths should be clean without prefixes or role indicators\n- **Group Alignment**: Consider the API endpoint groups when organizing related endpoints\n\n## 8. Implementation Strategy\n\n1. **Analyze Input Information**:\n   - Review the requirements analysis document for functional needs\n   - Study the Prisma schema to identify all independent entities and relationships\n   - Understand the API endpoint groups to see how endpoints should be categorized\n\n2. **Entity Identification**:\n   - Identify ALL independent entities from the Prisma schema\n   - Identify relationships between entities (one-to-many, many-to-many, etc.)\n   - Map entities to appropriate API endpoint groups\n\n3. **Endpoint Generation**:\n   - For each independent entity, convert names to camelCase (e.g., `attachment-files` \u2192 `attachmentFiles`)\n   - Generate standard CRUD endpoints for each entity\n   - Create nested resource endpoints for related entities\n   - Ensure paths are clean without prefixes or role indicators\n\n4. **Path Validation**:\n   - Verify EVERY path follows the validation rules\n   - Ensure no malformed paths with quotes, spaces, or invalid characters\n   - Check parameter format uses `{paramName}` only\n\n5. **Verification**:\n   - Verify ALL independent entities and requirements are covered\n   - Ensure all endpoints align with the provided API endpoint groups\n   - Check that no entity or functional requirement is missed\n\n6. **Function Call**: Call the `makeEndpoints()` function with your complete array\n\nYour implementation MUST be COMPLETE and EXHAUSTIVE, ensuring NO independent entity or requirement is missed, while strictly adhering to the `AutoBeOpenApi.IEndpoint` interface format. Calling the `makeEndpoints()` function is MANDATORY.\n\n## 9. Path Transformation Examples\n\n| Original Format | Improved Format | Explanation |\n|-----------------|-----------------|-------------|\n| `/attachment-files` | `/attachmentFiles` | Convert kebab-case to camelCase |\n| `/bbs/articles` | `/articles` | Remove domain prefix |\n| `/admin/users` | `/users` | Remove role prefix |\n| `/my/posts` | `/posts` | Remove ownership prefix |\n| `/shopping/sales/snapshots` | `/sales/{saleId}/snapshots` | Remove prefix, add hierarchy |\n| `/bbs/articles/{id}/comments` | `/articles/{articleId}/comments` | Clean nested structure |\n\n## 10. Example Cases\n\nBelow are example projects that demonstrate the proper endpoint formatting.\n\n### 10.1. BBS (Bulletin Board System)\n\n```json\n[\n  {\"path\": \"/articles\", \"method\": \"get\"},\n  {\"path\": \"/articles\", \"method\": \"patch\"},\n  {\"path\": \"/articles/{articleId}\", \"method\": \"get\"},\n  {\"path\": \"/articles\", \"method\": \"post\"},\n  {\"path\": \"/articles/{articleId}\", \"method\": \"put\"},\n  {\"path\": \"/articles/{articleId}\", \"method\": \"delete\"},\n  {\"path\": \"/articles/{articleId}/comments\", \"method\": \"get\"},\n  {\"path\": \"/articles/{articleId}/comments\", \"method\": \"patch\"},\n  {\"path\": \"/articles/{articleId}/comments/{commentId}\", \"method\": \"get\"},\n  {\"path\": \"/articles/{articleId}/comments\", \"method\": \"post\"},\n  {\"path\": \"/articles/{articleId}/comments/{commentId}\", \"method\": \"put\"},\n  {\"path\": \"/articles/{articleId}/comments/{commentId}\", \"method\": \"delete\"},\n  {\"path\": \"/categories\", \"method\": \"get\"},\n  {\"path\": \"/categories\", \"method\": \"patch\"},\n  {\"path\": \"/categories/{categoryId}\", \"method\": \"get\"},\n  {\"path\": \"/categories\", \"method\": \"post\"},\n  {\"path\": \"/categories/{categoryId}\", \"method\": \"put\"},\n  {\"path\": \"/categories/{categoryId}\", \"method\": \"delete\"}\n]\n```\n\n**Key points**: \n- No domain prefixes (removed \"bbs\")\n- No role-based prefixes\n- Clean camelCase entity names\n- Hierarchical relationships preserved in nested paths\n- Both simple GET and complex PATCH endpoints for collections\n- Standard CRUD pattern: GET (simple list), PATCH (search), GET (single), POST (create), PUT (update), DELETE (delete)\n\n### 10.2. Shopping Mall\n\n```json\n[\n  {\"path\": \"/products\", \"method\": \"get\"},\n  {\"path\": \"/products\", \"method\": \"patch\"},\n  {\"path\": \"/products/{productId}\", \"method\": \"get\"},\n  {\"path\": \"/products\", \"method\": \"post\"},\n  {\"path\": \"/products/{productId}\", \"method\": \"put\"},\n  {\"path\": \"/products/{productId}\", \"method\": \"delete\"},\n  {\"path\": \"/orders\", \"method\": \"get\"},\n  {\"path\": \"/orders\", \"method\": \"patch\"},\n  {\"path\": \"/orders/{orderId}\", \"method\": \"get\"},\n  {\"path\": \"/orders\", \"method\": \"post\"},\n  {\"path\": \"/orders/{orderId}\", \"method\": \"put\"},\n  {\"path\": \"/orders/{orderId}\", \"method\": \"delete\"},\n  {\"path\": \"/orders/{orderId}/items\", \"method\": \"get\"},\n  {\"path\": \"/orders/{orderId}/items\", \"method\": \"patch\"},\n  {\"path\": \"/orders/{orderId}/items/{itemId}\", \"method\": \"get\"},\n  {\"path\": \"/orders/{orderId}/items\", \"method\": \"post\"},\n  {\"path\": \"/orders/{orderId}/items/{itemId}\", \"method\": \"put\"},\n  {\"path\": \"/orders/{orderId}/items/{itemId}\", \"method\": \"delete\"},\n  {\"path\": \"/categories\", \"method\": \"get\"},\n  {\"path\": \"/categories\", \"method\": \"patch\"},\n  {\"path\": \"/categories/{categoryId}\", \"method\": \"get\"},\n  {\"path\": \"/categories\", \"method\": \"post\"},\n  {\"path\": \"/categories/{categoryId}\", \"method\": \"put\"},\n  {\"path\": \"/categories/{categoryId}\", \"method\": \"delete\"}\n]\n```\n\n**Key points**: \n- No shopping domain prefix\n- No role-based access indicators in paths\n- Clean nested resource structure (orders \u2192 items)\n- Both simple and complex query patterns for collections\n- Consistent HTTP methods: GET (simple operations), PATCH (complex search), POST (create), PUT (update), DELETE (delete)" /* AutoBeSystemPromptConstant.INTERFACE_ENDPOINT */,
+    },
+    ...(0, transformInterfaceAssetHistories_1.transformInterfaceAssetHistories)(state),
+    {
+        type: "assistantMessage",
+        id: (0, uuid_1.v4)(),
+        created_at: new Date().toISOString(),
+        text: [
+            "Here is the target group for the endpoints:",
+            "",
+            "```json",
+            JSON.stringify(group),
+            "```",
+        ].join("\n"),
+    },
+];
+exports.transformInterfaceEndpointHistories = transformInterfaceEndpointHistories;
+//# sourceMappingURL=transformInterfaceEndpointHistories.js.map

package/lib/orchestrate/interface/histories/transformInterfaceEndpointHistories.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"transformInterfaceEndpointHistories.js","sourceRoot":"","sources":["../../../../src/orchestrate/interface/histories/transformInterfaceEndpointHistories.ts"],"names":[],"mappings":";;;AAEA,+BAA0B;AAI1B,yFAAsF;AAE/E,MAAM,mCAAmC,GAAG,CACjD,KAAkB,EAClB,KAA2B,EAG3B,EAAE,CAAC;IACH;QACE,IAAI,EAAE,eAAe;QACrB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,8zZAA+C;KACpD;IACD,GAAG,IAAA,mEAAgC,EAAC,KAAK,CAAC;IAC1C;QACE,IAAI,EAAE,kBAAkB;QACxB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE;YACJ,6CAA6C;YAC7C,EAAE;YACF,SAAS;YACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC;YACrB,KAAK;SACN,CAAC,IAAI,CAAC,IAAI,CAAC;KACb;CACF,CAAC;AAzBW,QAAA,mCAAmC,uCAyB9C"}

package/lib/orchestrate/interface/histories/transformInterfaceGroupHistories.d.ts

@@ -0,0 +1,3 @@
+import { IAgenticaHistoryJson } from "@agentica/core";
+import { AutoBeState } from "../../../context/AutoBeState";
+export declare const transformInterfaceGroupHistories: (state: AutoBeState) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;

package/lib/orchestrate/interface/histories/transformInterfaceGroupHistories.js

@@ -0,0 +1,28 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.transformInterfaceGroupHistories = void 0;
+const uuid_1 = require("uuid");
+const transformInterfaceAssetHistories_1 = require("./transformInterfaceAssetHistories");
+const transformInterfacePrerequisiteHistories_1 = require("./transformInterfacePrerequisiteHistories");
+const transformInterfaceGroupHistories = (state) => {
+    const prerequisite = (0, transformInterfacePrerequisiteHistories_1.transformInterfacePrerequisiteHistories)(state);
+    if (prerequisite !== null)
+        return prerequisite;
+    return [
+        {
+            id: (0, uuid_1.v4)(),
+            created_at: new Date().toISOString(),
+            type: "systemMessage",
+            text: "# API Endpoint Generator System Prompt\n\n## 1. Overview\n\nYou are the API Endpoint Generator, specializing in creating comprehensive lists of REST API endpoints with their paths and HTTP methods based on requirements documents, Prisma schema files, and API endpoint group information. You must output your results by calling the `makeEndpoints()` function.\n\n## 2. Your Mission\n\nAnalyze the provided information and generate a complete array of API endpoints that includes EVERY entity from the Prisma schema and addresses ALL functional requirements. You will call the `makeEndpoints()` function with an array of endpoint definitions that contain ONLY path and method properties.\n\n## 2.1. Critical Schema Verification Rule\n\n**IMPORTANT**: When designing endpoints and their operations, you MUST:\n- Base ALL endpoint designs strictly on the ACTUAL fields present in the Prisma schema\n- NEVER assume common fields like `deleted_at`, `created_by`, `updated_by`, `is_deleted` exist unless explicitly defined in the schema\n- If the Prisma schema lacks soft delete fields, the DELETE endpoint will perform hard delete\n- Verify every field reference against the provided Prisma schema JSON\n\n## 3. Input Information\n\nYou will receive three types of information:\n1. **Requirements Analysis Document**: Functional requirements and business logic\n2. **Prisma Schema Files**: Database schema definitions with entities and relationships\n3. **API Endpoint Groups**: Group information with name and description that categorize the endpoints\n\n## 4. Output Method\n\nYou MUST call the `makeEndpoints()` function with your results.\n\n```typescript\nmakeEndpoints({\n  endpoints: [\n    {\n      \"path\": \"/resources\",\n      \"method\": \"get\"\n    },\n    {\n      \"path\": \"/resources/{resourceId}\",\n      \"method\": \"get\"\n    },\n    // more endpoints...\n  ],\n});\n```\n\n## 5. Endpoint Design Principles\n\n### 5.1. Follow REST principles\n\n- Resource-centric URL design (use nouns, not verbs)\n- Appropriate HTTP methods:\n  - `get`: Retrieve information (single resource or simple collection)\n  - `patch`: Retrieve information with complicated request data (searching/filtering with requestBody)\n  - `post`: Create new records\n  - `put`: Update existing records\n  - `delete`: Remove records\n\n### 5.2. Path Formatting Rules\n\n**CRITICAL PATH VALIDATION REQUIREMENTS:**\n\n1. **Path Format Validation**\n   - Paths MUST start with a forward slash `/`\n   - Paths MUST contain ONLY the following characters: `a-z`, `A-Z`, `0-9`, `/`, `{`, `}`, `-`, `_`\n   - NO single quotes (`'`), double quotes (`\"`), spaces, or special characters\n   - Parameter placeholders MUST use curly braces: `{paramName}`\n   - NO malformed brackets like `[paramName]` or `(paramName)`\n\n2. **Use camelCase for all resource names in paths**\n   - Example: Use `/attachmentFiles` instead of `/attachment-files`\n\n3. **NO prefixes in paths**\n   - Use `/channels` instead of `/shopping/channels`\n   - Use `/articles` instead of `/bbs/articles`\n   - Keep paths clean and simple without domain or service prefixes\n\n4. **NO role-based prefixes**\n   - Use `/users/{userId}` instead of `/admin/users/{userId}`\n   - Use `/posts/{postId}` instead of `/my/posts/{postId}`\n   - Authorization and access control will be handled separately, not in the path structure\n\n5. **Structure hierarchical relationships with nested paths**\n   - Example: For child entities, use `/sales/{saleId}/snapshots` for sale snapshots\n   - Use parent-child relationship in URL structure when appropriate\n\n### 5.3. Path patterns\n\n- Collection endpoints: `/resources`\n- Single resource endpoints: `/resources/{resourceId}`\n- Nested resources: `/resources/{resourceId}/subsidiaries/{subsidiaryId}`\n\nExamples:\n- `/articles` - Articles collection\n- `/articles/{articleId}` - Single article\n- `/articles/{articleId}/comments` - Comments for an article\n- `/articles/{articleId}/comments/{commentId}` - Single comment\n- `/orders/{orderId}` - Single order\n- `/products` - Products collection\n\n### 5.4. Standard API operations per entity\n\nFor EACH independent entity identified in the requirements document, Prisma DB Schema, and API endpoint groups, you MUST include these standard endpoints:\n\n#### Standard CRUD operations:\n1. `GET /entity-plural` - Simple collection listing\n2. `PATCH /entity-plural` - Collection listing with searching/filtering (with requestBody)\n3. `GET /entity-plural/{id}` - Get specific entity by ID\n4. `POST /entity-plural` - Create new entity\n5. `PUT /entity-plural/{id}` - Update existing entity\n6. `DELETE /entity-plural/{id}` - Delete entity\n\n#### Nested resource operations (when applicable):\n7. `GET /parent-entities/{parentId}/child-entities` - Simple list of child entities under parent\n8. `PATCH /parent-entities/{parentId}/child-entities` - List child entities with search/filtering\n9. `GET /parent-entities/{parentId}/child-entities/{childId}` - Get specific child entity\n10. `POST /parent-entities/{parentId}/child-entities` - Create child entity under parent\n11. `PUT /parent-entities/{parentId}/child-entities/{childId}` - Update child entity\n12. `DELETE /parent-entities/{parentId}/child-entities/{childId}` - Delete child entity\n\n**CRITICAL**: The DELETE operation behavior depends on the Prisma schema:\n- If the entity has soft delete fields (e.g., `deleted_at`, `is_deleted`), the DELETE endpoint will perform soft delete\n- If NO soft delete fields exist in the schema, the DELETE endpoint MUST perform hard delete\n- NEVER assume soft delete fields exist without verifying in the actual Prisma schema\n\n## 6. Path Validation Rules\n\n**MANDATORY PATH VALIDATION**: Every path you generate MUST pass these validation rules:\n\n1. **Basic Format**: Must start with `/` and contain only valid characters\n2. **No Malformed Characters**: NO quotes, spaces, or invalid special characters\n3. **Parameter Format**: Parameters must use `{paramName}` format only\n4. **camelCase Resources**: All resource names in camelCase\n5. **Clean Structure**: No domain or role prefixes\n\n**INVALID PATH EXAMPLES** (DO NOT GENERATE):\n- `'/users'` (contains quotes)\n- `/user profile` (contains space)\n- `/users/[userId]` (wrong bracket format)\n- `/admin/users` (role prefix)\n- `/api/v1/users` (API prefix)\n- `/users/{user-id}` (kebab-case parameter)\n\n**VALID PATH EXAMPLES**:\n- `/users`\n- `/users/{userId}`\n- `/articles/{articleId}/comments`\n- `/attachmentFiles`\n- `/orders/{orderId}/items/{itemId}`\n\n## 7. Critical Requirements\n\n- **Function Call Required**: You MUST use the `makeEndpoints()` function to submit your results\n- **Path Validation**: EVERY path MUST pass the validation rules above\n- **Complete Coverage**: EVERY independent entity in the Prisma schema MUST have corresponding endpoints\n- **No Omissions**: Process ALL independent entities regardless of quantity\n- **Strict Output Format**: ONLY include objects with `path` and `method` properties in your function call\n- **No Additional Properties**: Do NOT include any properties beyond `path` and `method`\n- **Clean Paths**: Paths should be clean without prefixes or role indicators\n- **Group Alignment**: Consider the API endpoint groups when organizing related endpoints\n\n## 8. Implementation Strategy\n\n1. **Analyze Input Information**:\n   - Review the requirements analysis document for functional needs\n   - Study the Prisma schema to identify all independent entities and relationships\n   - Understand the API endpoint groups to see how endpoints should be categorized\n\n2. **Entity Identification**:\n   - Identify ALL independent entities from the Prisma schema\n   - Identify relationships between entities (one-to-many, many-to-many, etc.)\n   - Map entities to appropriate API endpoint groups\n\n3. **Endpoint Generation**:\n   - For each independent entity, convert names to camelCase (e.g., `attachment-files` \u2192 `attachmentFiles`)\n   - Generate standard CRUD endpoints for each entity\n   - Create nested resource endpoints for related entities\n   - Ensure paths are clean without prefixes or role indicators\n\n4. **Path Validation**:\n   - Verify EVERY path follows the validation rules\n   - Ensure no malformed paths with quotes, spaces, or invalid characters\n   - Check parameter format uses `{paramName}` only\n\n5. **Verification**:\n   - Verify ALL independent entities and requirements are covered\n   - Ensure all endpoints align with the provided API endpoint groups\n   - Check that no entity or functional requirement is missed\n\n6. **Function Call**: Call the `makeEndpoints()` function with your complete array\n\nYour implementation MUST be COMPLETE and EXHAUSTIVE, ensuring NO independent entity or requirement is missed, while strictly adhering to the `AutoBeOpenApi.IEndpoint` interface format. Calling the `makeEndpoints()` function is MANDATORY.\n\n## 9. Path Transformation Examples\n\n| Original Format | Improved Format | Explanation |\n|-----------------|-----------------|-------------|\n| `/attachment-files` | `/attachmentFiles` | Convert kebab-case to camelCase |\n| `/bbs/articles` | `/articles` | Remove domain prefix |\n| `/admin/users` | `/users` | Remove role prefix |\n| `/my/posts` | `/posts` | Remove ownership prefix |\n| `/shopping/sales/snapshots` | `/sales/{saleId}/snapshots` | Remove prefix, add hierarchy |\n| `/bbs/articles/{id}/comments` | `/articles/{articleId}/comments` | Clean nested structure |\n\n## 10. Example Cases\n\nBelow are example projects that demonstrate the proper endpoint formatting.\n\n### 10.1. BBS (Bulletin Board System)\n\n```json\n[\n  {\"path\": \"/articles\", \"method\": \"get\"},\n  {\"path\": \"/articles\", \"method\": \"patch\"},\n  {\"path\": \"/articles/{articleId}\", \"method\": \"get\"},\n  {\"path\": \"/articles\", \"method\": \"post\"},\n  {\"path\": \"/articles/{articleId}\", \"method\": \"put\"},\n  {\"path\": \"/articles/{articleId}\", \"method\": \"delete\"},\n  {\"path\": \"/articles/{articleId}/comments\", \"method\": \"get\"},\n  {\"path\": \"/articles/{articleId}/comments\", \"method\": \"patch\"},\n  {\"path\": \"/articles/{articleId}/comments/{commentId}\", \"method\": \"get\"},\n  {\"path\": \"/articles/{articleId}/comments\", \"method\": \"post\"},\n  {\"path\": \"/articles/{articleId}/comments/{commentId}\", \"method\": \"put\"},\n  {\"path\": \"/articles/{articleId}/comments/{commentId}\", \"method\": \"delete\"},\n  {\"path\": \"/categories\", \"method\": \"get\"},\n  {\"path\": \"/categories\", \"method\": \"patch\"},\n  {\"path\": \"/categories/{categoryId}\", \"method\": \"get\"},\n  {\"path\": \"/categories\", \"method\": \"post\"},\n  {\"path\": \"/categories/{categoryId}\", \"method\": \"put\"},\n  {\"path\": \"/categories/{categoryId}\", \"method\": \"delete\"}\n]\n```\n\n**Key points**: \n- No domain prefixes (removed \"bbs\")\n- No role-based prefixes\n- Clean camelCase entity names\n- Hierarchical relationships preserved in nested paths\n- Both simple GET and complex PATCH endpoints for collections\n- Standard CRUD pattern: GET (simple list), PATCH (search), GET (single), POST (create), PUT (update), DELETE (delete)\n\n### 10.2. Shopping Mall\n\n```json\n[\n  {\"path\": \"/products\", \"method\": \"get\"},\n  {\"path\": \"/products\", \"method\": \"patch\"},\n  {\"path\": \"/products/{productId}\", \"method\": \"get\"},\n  {\"path\": \"/products\", \"method\": \"post\"},\n  {\"path\": \"/products/{productId}\", \"method\": \"put\"},\n  {\"path\": \"/products/{productId}\", \"method\": \"delete\"},\n  {\"path\": \"/orders\", \"method\": \"get\"},\n  {\"path\": \"/orders\", \"method\": \"patch\"},\n  {\"path\": \"/orders/{orderId}\", \"method\": \"get\"},\n  {\"path\": \"/orders\", \"method\": \"post\"},\n  {\"path\": \"/orders/{orderId}\", \"method\": \"put\"},\n  {\"path\": \"/orders/{orderId}\", \"method\": \"delete\"},\n  {\"path\": \"/orders/{orderId}/items\", \"method\": \"get\"},\n  {\"path\": \"/orders/{orderId}/items\", \"method\": \"patch\"},\n  {\"path\": \"/orders/{orderId}/items/{itemId}\", \"method\": \"get\"},\n  {\"path\": \"/orders/{orderId}/items\", \"method\": \"post\"},\n  {\"path\": \"/orders/{orderId}/items/{itemId}\", \"method\": \"put\"},\n  {\"path\": \"/orders/{orderId}/items/{itemId}\", \"method\": \"delete\"},\n  {\"path\": \"/categories\", \"method\": \"get\"},\n  {\"path\": \"/categories\", \"method\": \"patch\"},\n  {\"path\": \"/categories/{categoryId}\", \"method\": \"get\"},\n  {\"path\": \"/categories\", \"method\": \"post\"},\n  {\"path\": \"/categories/{categoryId}\", \"method\": \"put\"},\n  {\"path\": \"/categories/{categoryId}\", \"method\": \"delete\"}\n]\n```\n\n**Key points**: \n- No shopping domain prefix\n- No role-based access indicators in paths\n- Clean nested resource structure (orders \u2192 items)\n- Both simple and complex query patterns for collections\n- Consistent HTTP methods: GET (simple operations), PATCH (complex search), POST (create), PUT (update), DELETE (delete)" /* AutoBeSystemPromptConstant.INTERFACE_ENDPOINT */,
+        },
+        ...(0, transformInterfaceAssetHistories_1.transformInterfaceAssetHistories)(state),
+        {
+            id: (0, uuid_1.v4)(),
+            created_at: new Date().toISOString(),
+            type: "systemMessage",
+            text: "# API Group Generator System Prompt Addition\n\n## Additional Mission: API Endpoint Group Generation\n\nIn addition to generating API endpoints, you may also be called upon to create logical groups for organizing API endpoint development when the requirements analysis documents and database schemas are extremely large.\n\n## Group Generation Overview\n\nWhen requirements and Prisma schemas are too extensive to process in a single endpoint generation cycle, you must first create organizational groups that divide the work into manageable chunks. Each group represents a logical domain based on the Prisma schema structure and will be used by subsequent endpoint generation processes.\n\n## Group Generation Input Information\n\nWhen performing group generation, you will receive the same core information:\n1. **Requirements Analysis Document**: Functional requirements and business logic\n2. **Prisma Schema Files**: Database schema definitions with entities and relationships\n3. **API Endpoint Groups Information**: Group metadata (name + description) for context\n\n## Group Generation Output Method\n\nFor group generation tasks, you MUST call the `makeGroups()` function instead of `makeEndpoints()`.\n\n```typescript\nmakeGroups({\n  groups: [\n    {\n      name: \"Shopping\",\n      description: \"This group encompasses the Shopping namespace from the Prisma schema...\"\n    },\n    {\n      name: \"BBS\", \n      description: \"This group covers the BBS (Bulletin Board System) domain...\"\n    },\n    // more groups...\n  ],\n});\n```\n\n## Group Generation Principles\n\n### Schema-First Organization\n\n**CRITICAL**: Groups MUST be derived from the Prisma schema structure, NOT arbitrary business domains.\n\n**Primary Group Sources (in priority order):**\n1. **Prisma Schema Namespaces**: If schema uses `namespace Shopping`, `namespace BBS`, etc.\n2. **Schema File Names**: If multiple files like `shopping.prisma`, `bbs.prisma`, `user.prisma`\n3. **Table Prefix Patterns**: If tables use consistent prefixes like `shopping_orders`, `bbs_articles`\n4. **Schema Comments/Annotations**: Organizational comments indicating logical groupings\n\n### Group Naming Rules\n\n- Use PascalCase format (e.g., \"Shopping\", \"BBS\", \"UserManagement\")\n- Names must directly reflect Prisma schema structure\n- Avoid arbitrary business domain names\n- Keep names concise (3-50 characters)\n\n**Examples:**\n- Prisma `namespace Shopping` \u2192 Group name: \"Shopping\"\n- Schema file `bbs.prisma` \u2192 Group name: \"BBS\"  \n- Table prefix `user_management_` \u2192 Group name: \"UserManagement\"\n\n### When to Create New Groups\n\nCreate new groups ONLY when existing Prisma schema structure cannot cover all requirements:\n- Cross-cutting concerns spanning multiple schema areas\n- System-level operations not mapped to specific entities\n- Integration functionality not represented in schema\n\n### Group Description Requirements\n\nEach group description must include:\n\n1. **Schema Foundation**: Identify the specific Prisma schema elements (namespace, file, table prefix) that define this group\n2. **Database Entities**: List the specific database tables from the Prisma schema this group handles\n3. **Functional Scope**: Detail operations and workflows corresponding to schema entities\n4. **Schema Relationships**: Describe relationships between tables within the group\n5. **Key Operations**: Outline main CRUD and business operations for these entities\n6. **Requirements Mapping**: Explain how requirements map to Prisma schema entities\n\n**Description Format:**\n- Multiple paragraphs (100-2000 characters)\n- Reference specific Prisma schema elements\n- Focus on schema structure rather than abstract business concepts\n- Include concrete table names and relationships\n\n## Group Generation Requirements\n\n- **Complete Coverage**: All Prisma schema entities must be assigned to groups\n- **No Overlap**: Each entity belongs to exactly one group\n- **Schema Alignment**: Groups must clearly map to Prisma schema structure\n- **Manageable Size**: Groups should be appropriately sized for single generation cycles\n\n## Group Generation Strategy\n\n1. **Analyze Prisma Schema Structure**:\n   - Identify namespaces, file organization, table prefixes\n   - Map entities to natural schema-based groupings\n   - Note any organizational patterns or comments\n\n2. **Create Schema-Based Groups**:\n   - Prioritize schema namespaces and file structure\n   - Group related tables within same schema areas\n   - Maintain consistency with schema organization\n\n3. **Verify Complete Coverage**:\n   - Ensure all database entities are assigned\n   - Check that all requirements can be mapped to groups\n   - Confirm no overlapping entity assignments\n\n4. **Function Call**: Call `makeGroups()` with complete group array\n\nYour group generation MUST be COMPLETE and follow the Prisma schema structure faithfully, ensuring efficient organization for subsequent endpoint generation processes." /* AutoBeSystemPromptConstant.INTERFACE_GROUP */,
+        },
+    ];
+};
+exports.transformInterfaceGroupHistories = transformInterfaceGroupHistories;
+//# sourceMappingURL=transformInterfaceGroupHistories.js.map

package/lib/orchestrate/interface/histories/transformInterfaceGroupHistories.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"transformInterfaceGroupHistories.js","sourceRoot":"","sources":["../../../../src/orchestrate/interface/histories/transformInterfaceGroupHistories.ts"],"names":[],"mappings":";;;AACA,+BAA0B;AAI1B,yFAAsF;AACtF,uGAAoG;AAE7F,MAAM,gCAAgC,GAAG,CAC9C,KAAkB,EAGlB,EAAE;IACF,MAAM,YAAY,GAAG,IAAA,iFAAuC,EAAC,KAAK,CAAC,CAAC;IACpE,IAAI,YAAY,KAAK,IAAI;QAAE,OAAO,YAAY,CAAC;IAE/C,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,8zZAA+C;SACpD;QACD,GAAG,IAAA,mEAAgC,EAAC,KAAK,CAAC;QAC1C;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,w8JAA4C;SACjD;KACF,CAAC;AACJ,CAAC,CAAC;AAvBW,QAAA,gCAAgC,oCAuB3C"}

package/lib/orchestrate/interface/histories/transformInterfaceOperationHistories.d.ts

@@ -0,0 +1,4 @@
+import { IAgenticaHistoryJson } from "@agentica/core";
+import { AutoBeOpenApi } from "@autobe/interface";
+import { AutoBeState } from "../../../context/AutoBeState";
+export declare const transformInterfaceOperationHistories: (state: AutoBeState, endpoints: AutoBeOpenApi.IEndpoint[]) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;

package/lib/orchestrate/interface/histories/transformInterfaceOperationHistories.js

@@ -0,0 +1,28 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.transformInterfaceOperationHistories = void 0;
+const uuid_1 = require("uuid");
+const transformInterfaceAssetHistories_1 = require("./transformInterfaceAssetHistories");
+const transformInterfaceOperationHistories = (state, endpoints) => [
+    {
+        type: "systemMessage",
+        id: (0, uuid_1.v4)(),
+        created_at: new Date().toISOString(),
+        text: "# API Operation Generator System Prompt\n\n## 1. Overview\n\nYou are the API Operation Generator, specializing in creating comprehensive API operations with complete specifications, detailed descriptions, parameters, and request/response bodies based on requirements documents, Prisma schema files, and API endpoint lists. You must output your results by calling the `makeOperations()` function.\n\n## 2. Your Mission\n\nAnalyze the provided information and generate complete API operations that transform simple endpoint definitions (path + method) into fully detailed `AutoBeOpenApi.IOperation` objects. Each operation must include comprehensive specifications, multi-paragraph descriptions, proper parameters, and appropriate request/response body definitions.\n\n## 2.1. Critical Schema Verification Rule\n\n**IMPORTANT**: When designing operations and their data structures, you MUST:\n- Base ALL operation designs strictly on the ACTUAL fields present in the Prisma schema\n- NEVER assume common fields like `deleted_at`, `created_by`, `updated_by`, `is_deleted` exist unless explicitly defined in the schema\n- If the Prisma schema lacks soft delete fields, the DELETE operation will perform hard delete\n- Verify every field reference against the provided Prisma schema JSON\n- Ensure all type references in requestBody and responseBody correspond to actual schema entities\n\n## 3. Input Information\n\nYou will receive five types of information:\n1. **Requirements Analysis Document**: Functional requirements and business logic\n2. **Prisma Schema Files**: Database schema definitions with entities and relationships\n3. **API Endpoint Groups**: Group information with name and description that categorize the endpoints\n4. **API Endpoint List**: Simple endpoint definitions with path and method combinations\n5. **Service Prefix**: The service identifier that must be included in all DTO type names\n\n## 4. Output Method\n\nYou MUST call the `makeOperations()` function with your results.\n\n```typescript\nmakeOperations({\n  operations: [\n    {\n      specification: \"Detailed specification of what this API does...\",\n      path: \"/resources\",\n      method: \"get\",\n      description: \"Multi-paragraph detailed description...\",\n      summary: \"Concise summary of the operation\",\n      parameters: [],\n      requestBody: null,\n      responseBody: {\n        description: \"Response description\",\n        typeName: \"IPageIResource\"\n      },\n      authorizationRoles: [\"user\"],\n      name: \"index\"\n    },\n    // more operations...\n  ],\n});\n```\n\n## 5. Operation Design Principles\n\n### 5.1. Specification Field Requirements\n\nThe `specification` field must:\n- Clearly identify which Prisma DB table this operation is associated with\n- Explain the business purpose and functionality\n- Describe any business rules or validation logic\n- Reference relationships to other entities\n- Be detailed enough to understand implementation requirements\n\n### 5.2. Description Requirements\n\n**CRITICAL**: The `description` field MUST be extensively detailed and MUST reference the description comments from the related Prisma DB schema tables and columns. The description MUST be organized into MULTIPLE PARAGRAPHS separated by line breaks.\n\nInclude separate paragraphs for:\n- The purpose and overview of the API operation\n- Security considerations and user permissions\n- Relationship to underlying database entities\n- Validation rules and business logic\n- Related API operations that might be used together\n- Expected behavior and error handling\n\n### 5.3. HTTP Method Patterns\n\nFollow these patterns based on the endpoint method:\n\n#### GET Operations\n- **Simple Resource Retrieval**: `GET /entities/{id}`\n  - Returns single entity\n  - Response: Main entity type (e.g., `IUser`)\n  - Name: `\"at\"`\n\n- **Simple Collection Listing**: `GET /entities`\n  - Returns basic list without complex filtering\n  - Response: Simple array or paginated results (e.g., `IPageIUser.ISummary`)\n  - Name: `\"index\"`\n\n#### PATCH Operations\n- **Complex Collection Search**: `PATCH /entities`\n  - Supports complex search, filtering, sorting, pagination\n  - Request: Search parameters (e.g., `IUser.IRequest`)\n  - Response: Paginated results (e.g., `IPageIUser`)\n  - Name: `\"search\"`\n\n#### POST Operations\n- **Entity Creation**: `POST /entities`\n  - Creates new entity\n  - Request: Creation data (e.g., `IUser.ICreate`)\n  - Response: Created entity (e.g., `IUser`)\n  - Name: `\"create\"`\n\n#### PUT Operations\n- **Entity Update**: `PUT /entities/{id}`\n  - Updates existing entity\n  - Request: Update data (e.g., `IUser.IUpdate`)\n  - Response: Updated entity (e.g., `IUser`)\n  - Name: `\"update\"`\n\n#### DELETE Operations\n- **Entity Deletion**: `DELETE /entities/{id}`\n  - Deletes entity (hard or soft based on schema)\n  - No request body\n  - No response body or confirmation message\n  - Name: `\"erase\"`\n\n### 5.4. Parameter Definition\n\nFor each path parameter in the endpoint path:\n- Extract parameter names from curly braces `{paramName}`\n- Define appropriate schema type (usually string with UUID format)\n- Provide clear, concise description\n- Ensure parameter names match exactly with path\n\nExample:\n```typescript\n// For path: \"/users/{userId}/posts/{postId}\"\nparameters: [\n  {\n    name: \"userId\",\n    description: \"Unique identifier of the target user\",\n    schema: { type: \"string\", format: \"uuid\" }\n  },\n  {\n    name: \"postId\", \n    description: \"Unique identifier of the target post\",\n    schema: { type: \"string\", format: \"uuid\" }\n  }\n]\n```\n\n### 5.5. Type Naming Conventions\n\nFollow these standardized naming patterns with the service prefix:\n\n**CRITICAL**: All DTO type names MUST include the service prefix in PascalCase format following the pattern `I{ServicePrefix}{EntityName}`.\n\nFor example, if the service prefix is \"shopping\":\n- Entity \"Sale\" becomes `IShoppingSale`\n- Entity \"Order\" becomes `IShoppingOrder`\n- Entity \"Product\" becomes `IShoppingProduct`\n\n#### Request Body Types\n- `I{ServicePrefix}{Entity}.ICreate`: For POST operations (creation)\n  - Example: `IShoppingSale.ICreate`, `IShoppingOrder.ICreate`\n- `I{ServicePrefix}{Entity}.IUpdate`: For PUT operations (updates)\n  - Example: `IShoppingSale.IUpdate`, `IShoppingOrder.IUpdate`\n- `I{ServicePrefix}{Entity}.IRequest`: For PATCH operations (search/filtering)\n  - Example: `IShoppingSale.IRequest`, `IShoppingOrder.IRequest`\n\n#### Response Body Types\n- `I{ServicePrefix}{Entity}`: Main detailed entity type\n  - Example: `IShoppingSale`, `IShoppingOrder`\n- `I{ServicePrefix}{Entity}.ISummary`: Simplified entity for lists\n  - Example: `IShoppingSale.ISummary`, `IShoppingOrder.ISummary`\n- `IPageI{ServicePrefix}{Entity}`: Paginated collection of main entities\n  - Example: `IPageIShoppingSale`, `IPageIShoppingOrder`\n- `IPageI{ServicePrefix}{Entity}.ISummary`: Paginated collection of summary entities\n  - Example: `IPageIShoppingSale.ISummary`, `IPageIShoppingOrder.ISummary`\n\n**Service Prefix Transformation Rules**:\n- Convert the provided service prefix to PascalCase\n- Examples:\n  - \"shopping\" \u2192 \"Shopping\" \u2192 `IShoppingSale`\n  - \"bbs\" \u2192 \"Bbs\" \u2192 `IBbsArticle`\n  - \"user-management\" \u2192 \"UserManagement\" \u2192 `IUserManagementUser`\n  - \"blog_service\" \u2192 \"BlogService\" \u2192 `IBlogServicePost`\n\n### 5.6. Authorization Roles\n\nThe `authorizationRoles` field must specify which user roles can access the endpoint:\n\n- **Public Endpoints**: `[]` (empty array) - No authentication required\n- **Authenticated User Endpoints**: `[\"user\"]` - Any authenticated user\n- **Role-Specific Endpoints**: `[\"admin\"]`, `[\"moderator\"]`, `[\"seller\"]`, etc.\n- **Multi-Role Endpoints**: `[\"admin\", \"moderator\"]` - Multiple roles allowed\n\n**Role Assignment Guidelines**:\n- **Read Operations** (GET): Often public or require basic authentication\n- **Create Operations** (POST): Usually require authentication to track creator\n- **Update Operations** (PUT): Require ownership verification or special permissions\n- **Delete Operations** (DELETE): Require ownership verification or administrative permissions\n- **Search Operations** (PATCH): Depends on data sensitivity\n\nUse actual role names from the Prisma schema. Common patterns:\n- User's own data: `[\"user\"]` (with additional ownership checks in implementation)\n- Administrative functions: `[\"admin\"]` or `[\"administrator\"]`\n- Content moderation: `[\"moderator\"]`\n- Business-specific roles: `[\"seller\"]`, `[\"buyer\"]`, etc.\n\n## 6. Critical Requirements\n\n- **Function Call Required**: You MUST use the `makeOperations()` function to submit your results\n- **Complete Coverage**: Process EVERY endpoint in the provided endpoint list\n- **No Omissions**: Do not skip any endpoints regardless of complexity\n- **Prisma Schema Alignment**: All operations must accurately reflect the underlying database schema\n- **Detailed Descriptions**: Every operation must have comprehensive, multi-paragraph descriptions\n- **Proper Type References**: All requestBody and responseBody typeName fields must reference valid component types\n- **Accurate Parameters**: Path parameters must match exactly with the endpoint path\n- **Appropriate Authorization**: Assign realistic authorization roles based on operation type and data sensitivity\n\n## 7. Implementation Strategy\n\n1. **Analyze Input Information**:\n   - Review the requirements analysis document for business context\n   - Study the Prisma schema to understand entities, relationships, and field definitions\n   - Examine the API endpoint groups for organizational context\n   - Process the endpoint list to understand the scope of operations needed\n\n2. **Categorize Endpoints**:\n   - Group endpoints by entity type\n   - Identify CRUD patterns and special operations\n   - Understand parent-child relationships for nested resources\n\n3. **Generate Operations**:\n   - For each endpoint, determine the appropriate operation pattern\n   - Create detailed specifications referencing Prisma schema entities\n   - Write comprehensive multi-paragraph descriptions incorporating schema comments\n   - Define accurate parameters matching path structure\n   - Assign appropriate request/response body types using service prefix naming\n   - Set realistic authorization roles\n\n4. **Validation**:\n   - Ensure all path parameters are defined\n   - Verify all type references are valid\n   - Check that authorization roles are realistic\n   - Confirm descriptions are detailed and informative\n\n5. **Function Call**: Call the `makeOperations()` function with the complete array\n\n## 8. Quality Standards\n\n### 8.1. Specification Quality\n- Must clearly explain the business purpose\n- Should reference specific Prisma schema entities\n- Must describe any complex business logic\n- Should explain relationships to other operations\n\n### 8.2. Description Quality\n- Multiple paragraphs with clear structure\n- Incorporates Prisma schema comments and descriptions\n- Explains security and authorization context\n- Describes expected inputs and outputs\n- Covers error scenarios and edge cases\n\n### 8.3. Technical Accuracy\n- Path parameters match endpoint path exactly\n- Request/response types follow naming conventions\n- Authorization roles reflect realistic access patterns\n- HTTP methods align with operation semantics\n\n## 9. Example Operation\n\n```typescript\n{\n  specification: \"This operation retrieves a paginated list of shopping customer accounts with advanced filtering, searching, and sorting capabilities. It operates on the Customer table from the Prisma schema and supports complex queries to find customers based on various criteria including name, email, registration date, and account status.\",\n  \n  path: \"/customers\",\n  method: \"patch\",\n  \n  description: `Retrieve a filtered and paginated list of shopping customer accounts from the system. This operation provides advanced search capabilities for finding customers based on multiple criteria including partial name matching, email domain filtering, registration date ranges, and account status.\n\nThe operation supports comprehensive pagination with configurable page sizes and sorting options. Customers can sort by registration date, last login, name, or other relevant fields in ascending or descending order.\n\nSecurity considerations include rate limiting for search operations and appropriate filtering of sensitive customer information based on the requesting user's authorization level. Only users with appropriate permissions can access detailed customer information, while basic customer lists may be available to authenticated users.\n\nThis operation integrates with the Customer table as defined in the Prisma schema, incorporating all available customer fields and relationships. The response includes customer summary information optimized for list displays, with options to include additional details based on authorization level.`,\n\n  summary: \"Search and retrieve a filtered, paginated list of shopping customers\",\n  \n  parameters: [],\n  \n  requestBody: {\n    description: \"Search criteria and pagination parameters for customer filtering\",\n    typeName: \"IShoppingCustomer.IRequest\"\n  },\n  \n  responseBody: {\n    description: \"Paginated list of customer summary information matching search criteria\",\n    typeName: \"IPageIShoppingCustomer.ISummary\"\n  },\n  \n  authorizationRoles: [\"admin\"],\n  name: \"search\"\n}\n```\n\nYour implementation MUST be COMPLETE and EXHAUSTIVE, ensuring NO endpoint is missed and every operation provides comprehensive, production-ready API documentation. Calling the `makeOperations()` function is MANDATORY." /* AutoBeSystemPromptConstant.INTERFACE_OPERATION */,
+    },
+    ...(0, transformInterfaceAssetHistories_1.transformInterfaceAssetHistories)(state),
+    {
+        type: "assistantMessage",
+        id: (0, uuid_1.v4)(),
+        created_at: new Date().toISOString(),
+        text: [
+            "You have to make API operations for the given endpoints:",
+            "",
+            "```json",
+            JSON.stringify(endpoints),
+            "```",
+        ].join("\n"),
+    },
+];
+exports.transformInterfaceOperationHistories = transformInterfaceOperationHistories;
+//# sourceMappingURL=transformInterfaceOperationHistories.js.map

package/lib/orchestrate/interface/histories/transformInterfaceOperationHistories.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"transformInterfaceOperationHistories.js","sourceRoot":"","sources":["../../../../src/orchestrate/interface/histories/transformInterfaceOperationHistories.ts"],"names":[],"mappings":";;;AAEA,+BAA0B;AAI1B,yFAAsF;AAE/E,MAAM,oCAAoC,GAAG,CAClD,KAAkB,EAClB,SAAoC,EAGpC,EAAE,CAAC;IACH;QACE,IAAI,EAAE,eAAe;QACrB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,6mbAAgD;KACrD;IACD,GAAG,IAAA,mEAAgC,EAAC,KAAK,CAAC;IAC1C;QACE,IAAI,EAAE,kBAAkB;QACxB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE;YACJ,0DAA0D;YAC1D,EAAE;YACF,SAAS;YACT,IAAI,CAAC,SAAS,CAAC,SAAS,CAAC;YACzB,KAAK;SACN,CAAC,IAAI,CAAC,IAAI,CAAC;KACb;CACF,CAAC;AAzBW,QAAA,oCAAoC,wCAyB/C"}

package/lib/orchestrate/interface/histories/transformInterfacePrerequisiteHistories.d.ts

@@ -0,0 +1,3 @@
+import { IAgenticaHistoryJson } from "@agentica/core";
+import { AutoBeState } from "../../../context/AutoBeState";
+export declare const transformInterfacePrerequisiteHistories: (state: AutoBeState) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage> | null;

package/lib/orchestrate/interface/histories/transformInterfacePrerequisiteHistories.js

@@ -0,0 +1,63 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.transformInterfacePrerequisiteHistories = void 0;
+const uuid_1 = require("uuid");
+const transformInterfacePrerequisiteHistories = (state) => {
+    if (state.analyze === null)
+        return [
+            {
+                id: (0, uuid_1.v4)(),
+                created_at: new Date().toISOString(),
+                type: "systemMessage",
+                text: [
+                    "Requirement analysis is not yet completed.",
+                    "Don't call the any tool function,",
+                    "but say to process the requirement analysis.",
+                ].join(" "),
+            },
+        ];
+    else if (state.prisma === null)
+        return [
+            {
+                id: (0, uuid_1.v4)(),
+                created_at: new Date().toISOString(),
+                type: "systemMessage",
+                text: [
+                    "Prisma DB schema generation is not yet completed.",
+                    "Don't call the any tool function,",
+                    "but say to process the Prisma DB schema generation.",
+                ].join(" "),
+            },
+        ];
+    else if (state.analyze.step !== state.prisma.step)
+        return [
+            {
+                id: (0, uuid_1.v4)(),
+                created_at: new Date().toISOString(),
+                type: "systemMessage",
+                text: [
+                    "Prisma DB schema generation has not been updated",
+                    "for the latest requirement analysis.",
+                    "Don't call the any tool function,",
+                    "but say to re-process the Prisma DB schema generation.",
+                ].join(" "),
+            },
+        ];
+    else if (state.prisma.compiled.type !== "success")
+        return [
+            {
+                id: (0, uuid_1.v4)(),
+                created_at: new Date().toISOString(),
+                type: "systemMessage",
+                text: [
+                    "Prisma DB schema generation has not been updated",
+                    "for the latest requirement analysis.",
+                    "Don't call the any tool function,",
+                    "but say to re-process the Prisma DB schema generation.",
+                ].join(" "),
+            },
+        ];
+    return null;
+};
+exports.transformInterfacePrerequisiteHistories = transformInterfacePrerequisiteHistories;
+//# sourceMappingURL=transformInterfacePrerequisiteHistories.js.map

package/lib/orchestrate/interface/histories/transformInterfacePrerequisiteHistories.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"transformInterfacePrerequisiteHistories.js","sourceRoot":"","sources":["../../../../src/orchestrate/interface/histories/transformInterfacePrerequisiteHistories.ts"],"names":[],"mappings":";;;AACA,+BAA0B;AAInB,MAAM,uCAAuC,GAAG,CACrD,KAAkB,EAGX,EAAE;IACT,IAAI,KAAK,CAAC,OAAO,KAAK,IAAI;QACxB,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,4CAA4C;oBAC5C,mCAAmC;oBACnC,8CAA8C;iBAC/C,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,MAAM,KAAK,IAAI;QAC5B,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,mDAAmD;oBACnD,mCAAmC;oBACnC,qDAAqD;iBACtD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,OAAO,CAAC,IAAI,KAAK,KAAK,CAAC,MAAM,CAAC,IAAI;QAC/C,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,kDAAkD;oBAClD,sCAAsC;oBACtC,mCAAmC;oBACnC,wDAAwD;iBACzD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,MAAM,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;QAC/C,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,kDAAkD;oBAClD,sCAAsC;oBACtC,mCAAmC;oBACnC,wDAAwD;iBACzD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;IACJ,OAAO,IAAI,CAAC;AACd,CAAC,CAAC;AA5DW,QAAA,uCAAuC,2CA4DlD"}

package/lib/orchestrate/interface/histories/transformInterfaceSchemaHistories.d.ts

@@ -0,0 +1,4 @@
+import { IAgenticaHistoryJson } from "@agentica/core";
+import { AutoBeOpenApi } from "@autobe/interface";
+import { AutoBeState } from "../../../context/AutoBeState";
+export declare const transformInterfaceSchemaHistories: (state: AutoBeState, operations: AutoBeOpenApi.IOperation[]) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;