@autobe/agent 0.19.1 → 0.21.0

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

@@ -1,40 +1,41 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.transformInterfaceEndpointHistories = void 0;
+const utils_1 = require("@autobe/utils");
 const uuid_1 = require("uuid");
 const transformInterfaceAssetHistories_1 = require("./transformInterfaceAssetHistories");
 const transformInterfaceEndpointHistories = (state, group, authorizations) => [
     {
         type: "systemMessage",
-        id: (0, uuid_1.v4)(),
+        id: (0, uuid_1.v7)(),
         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\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the endpoints directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n## 2. Your Mission\n\nAnalyze the provided information and generate a SELECTIVE array of API endpoints that addresses the functional requirements while being conservative about system-managed entities. You will call the `makeEndpoints()` function with an array of endpoint definitions that contain ONLY path and method properties.\n\n**CRITICAL: Conservative Endpoint Generation Philosophy**\n- NOT every table in the Prisma schema needs API endpoints\n- Focus on entities that users actually interact with\n- Skip system-managed tables that are handled internally\n- Quality over quantity - fewer well-designed endpoints are better than exhaustive coverage\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- **Check the `stance` property and generate endpoints accordingly**: \n  - Tables with `stance: \"primary\"` \u2192 Full CRUD endpoints (PATCH, GET, POST, PUT, DELETE)\n  - Tables with `stance: \"subsidiary\"` \u2192 Nested endpoints through parent only, NO independent operations\n  - Tables with `stance: \"snapshot\"` \u2192 Read-only endpoints (GET, PATCH for search), NO write operations\n\n## 2.2. System-Generated Data Restrictions\n\n**\u26A0\uFE0F CRITICAL**: Do NOT create endpoints for tables that are system-managed:\n\n**Identify System Tables by:**\n- Requirements saying \"THE system SHALL automatically [log/track/record]...\"\n- Tables that capture side effects of other operations\n- Data that no user would ever manually create/edit/delete\n\n**Common System Table Examples (context-dependent):**\n- Audit logs, audit trails\n- System metrics, performance data\n- Analytics events, tracking data\n- Login history, access logs\n- Operational logs\n\n**For System Tables:**\n- \u2705 MAY create GET endpoints for viewing (if users need to see the data)\n- \u2705 MAY create PATCH endpoints for searching/filtering\n- \u274C NEVER create POST endpoints (system creates these automatically)\n- \u274C NEVER create PUT endpoints (system data is immutable)\n- \u274C NEVER create DELETE endpoints (audit/compliance data must be preserved)\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\": \"patch\"\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. **CRITICAL: Snapshot tables must be hidden from API paths**\n   - **NEVER expose snapshot tables or \"snapshot\" keyword in API endpoint paths**\n   - **Even if a table is directly related to a snapshot table, do NOT reference the snapshot relationship in the path**\n   - Example: `shopping_sale_snapshot_review_comments` \u2192 `/shopping/sales/{saleId}/reviews/comments` \n     * NOT `/shopping/sales/snapshots/reviews/comments`\n     * NOT `/shopping/sales/{saleId}/snapshots/{snapshotId}/reviews/comments`\n   - Example: `bbs_article_snapshots` \u2192 `/articles` (the snapshot table itself becomes just `/articles`)\n   - Example: `bbs_article_snapshot_files` \u2192 `/articles/{articleId}/files` (files connected to snapshots are accessed as if connected to articles)\n   - Snapshot tables are internal implementation details for versioning/history and must be completely hidden from REST API design\n   - The API should present a clean business-oriented interface without exposing the underlying snapshot architecture\n\n5. **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\n6. **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**IMPORTANT**: All descriptions throughout the API design MUST be written in English. Never use other languages.\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 **primary business entity** identified in the requirements document, Prisma DB Schema, and API endpoint groups, consider including these standard endpoints:\n\n#### Standard CRUD operations:\n1. `PATCH /entity-plural` - Collection listing with searching/filtering (with requestBody)\n2. `GET /entity-plural/{id}` - Get specific entity by ID\n3. `POST /entity-plural` - Create new entity\n4. `PUT /entity-plural/{id}` - Update existing entity\n5. `DELETE /entity-plural/{id}` - Delete entity\n\n#### Nested resource operations (when applicable):\n6. `PATCH /parent-entities/{parentId}/child-entities` - List child entities with search/filtering\n7. `GET /parent-entities/{parentId}/child-entities/{childId}` - Get specific child entity\n8.  `POST /parent-entities/{parentId}/child-entities` - Create child entity under parent\n9.  `PUT /parent-entities/{parentId}/child-entities/{childId}` - Update child entity\n10.  `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### 5.5. Entity-Specific Restrictions\n\n**DO NOT CREATE:**\n- User creation endpoints (POST /users, POST /admins)\n- Authentication endpoints (handled separately)\n- Focus only on business data operations\n\nCreate operations for DIFFERENT paths and DIFFERENT purposes only.\n\n**IMPORTANT**: Some entities have special handling requirements and should NOT follow standard CRUD patterns:\n\n#### User/Authentication Entities (DO NOT CREATE):\n\n- **NO user creation endpoints**: `POST /users`, `POST /admins`, `POST /members`\n- **NO authentication endpoints**: Login, signup, registration are handled separately\n- **Reason**: User management and authentication are handled by dedicated systems\n\n#### Focus on Business Logic Only:\n\n- Create endpoints for business data operations\n- Create endpoints for domain-specific functionality  \n- Skip system/infrastructure entities like users, roles, permissions\n\n**Examples of what NOT to create:**\n\n```json\n{\"path\": \"/users\", \"method\": \"post\"}          // Don't create\n{\"path\": \"/admins\", \"method\": \"post\"}         // Don't create  \n{\"path\": \"/auth/login\", \"method\": \"post\"}     // Don't create\n```\n\n**Examples of what TO create:**\n\n```json\n{\"path\": \"/products\", \"method\": \"post\"}       // Business entity\n{\"path\": \"/orders\", \"method\": \"post\"}         // Business entity\n{\"path\": \"/users/{userId}\", \"method\": \"get\"}  // Profile retrieval OK\n```\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- **Selective Coverage**: Generate endpoints for PRIMARY business entities, not every table\n- **Conservative Approach**: Skip system-managed tables and subsidiary/snapshot tables unless explicitly needed\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 (Selective)**:\n   - Evaluate each entity's `stance` property carefully\n   \n   **For PRIMARY stance entities**:\n   - \u2705 Generate PATCH `/entities` - Search/filter with complex criteria across ALL instances\n   - \u2705 Generate GET `/entities/{id}` - Retrieve specific entity\n   - \u2705 Generate POST `/entities` - Create new entity independently\n   - \u2705 Generate PUT `/entities/{id}` - Update entity\n   - \u2705 Generate DELETE `/entities/{id}` - Delete entity\n   - Example: `bbs_article_comments` is PRIMARY because users need to:\n     * Search all comments by a user across all articles\n     * Moderate comments independently\n     * Edit/delete their comments directly\n   \n   **For SUBSIDIARY stance entities**:\n   - \u274C NO independent creation endpoints (managed through parent)\n   - \u274C NO independent search across all instances\n   - \u2705 MAY have GET `/parent/{parentId}/subsidiaries` - List within parent context\n   - \u2705 MAY have POST `/parent/{parentId}/subsidiaries` - Create through parent\n   - \u2705 MAY have PUT `/parent/{parentId}/subsidiaries/{id}` - Update through parent\n   - \u2705 MAY have DELETE `/parent/{parentId}/subsidiaries/{id}` - Delete through parent\n   - Example: `bbs_article_snapshot_files` - files attached to snapshots, managed via snapshot operations\n   \n   **For SNAPSHOT stance entities**:\n   - \u2705 Generate GET `/entities/{id}` - View historical state\n   - \u2705 Generate PATCH `/entities` - Search/filter historical data (read-only)\n   - \u274C NO POST endpoints - Snapshots are created automatically by system\n   - \u274C NO PUT endpoints - Historical data is immutable\n   - \u274C NO DELETE endpoints - Audit trail must be preserved\n   - Example: `bbs_article_snapshots` - historical states for audit/versioning\n   - Convert names to camelCase (e.g., `attachment-files` \u2192 `attachmentFiles`)\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 SELECTIVE and THOUGHTFUL, focusing on entities that users actually interact with while avoiding unnecessary endpoints for system-managed tables. Generate endpoints that serve real business needs, not exhaustive coverage of every database table. 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| `/shopping/sales/snapshots/reviews/comments` | `/shopping/sales/{saleId}/reviews/comments` | Remove \"snapshot\" - it's implementation detail |\n| `/bbs/articles/snapshots` | `/articles` | Remove \"snapshot\" from all paths |\n| `/bbs/articles/snapshots/files` | `/articles/{articleId}/files` | Always remove \"snapshot\" from paths |\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\": \"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\": \"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\": \"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: PATCH (search), GET (single), POST (create), PUT (update), DELETE (delete)\n\n### 10.2. Shopping Mall\n\n```json\n[\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\": \"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\": \"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\": \"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)(),
+        id: (0, uuid_1.v7)(),
         created_at: new Date().toISOString(),
-        text: [
-            "Here is the target group for the endpoints:",
-            "",
-            "```json",
-            JSON.stringify(group),
-            "```",
-            "",
-            "**IMPORTANT: DO NOT DUPLICATE EXISTING OPERATIONS**",
-            "",
-            "These operations already exist. Do NOT create similar endpoints:",
-            "",
-            "```json",
-            JSON.stringify(authorizations.map((op) => ({
-                path: op.path,
-                method: op.method,
-                name: op.name,
-                summary: op.summary,
-            }))),
-            "```",
-        ].join("\n"),
+        text: utils_1.StringUtil.trim `
+      Here is the target group for the endpoints:
+
+      \`\`\`json
+      ${JSON.stringify(group)}
+      \`\`\`
+
+      **IMPORTANT: DO NOT DUPLICATE EXISTING OPERATIONS**
+
+      These operations already exist. Do NOT create similar endpoints:
+
+      \`\`\`json
+      ${JSON.stringify(authorizations.map((op) => ({
+            path: op.path,
+            method: op.method,
+            name: op.name,
+            summary: op.summary,
+        })))}
+      \`\`\`
+    `,
     },
 ];
 exports.transformInterfaceEndpointHistories = transformInterfaceEndpointHistories;

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

@@ -1 +1 @@
-{"version":3,"file":"transformInterfaceEndpointHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/interface/histories/transformInterfaceEndpointHistories.ts"],"names":[],"mappings":";;;AAGA,+BAA0B;AAI1B,yFAAsF;AAE/E,MAAM,mCAAmC,GAAG,CACjD,KAAkB,EAClB,KAA2B,EAC3B,cAA0C,EAG1C,EAAE,CAAC;IACH;QACE,IAAI,EAAE,eAAe;QACrB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,ynnBAA+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;YACL,EAAE;YACF,qDAAqD;YACrD,EAAE;YACF,kEAAkE;YAClE,EAAE;YACF,SAAS;YACT,IAAI,CAAC,SAAS,CACZ,cAAc,CAAC,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,CAAC;gBAC1B,IAAI,EAAE,EAAE,CAAC,IAAI;gBACb,MAAM,EAAE,EAAE,CAAC,MAAM;gBACjB,IAAI,EAAE,EAAE,CAAC,IAAI;gBACb,OAAO,EAAE,EAAE,CAAC,OAAO;aACpB,CAAC,CAAC,CACJ;YACD,KAAK;SACN,CAAC,IAAI,CAAC,IAAI,CAAC;KACb;CACF,CAAC;AAzCW,QAAA,mCAAmC,uCAyC9C"}
+{"version":3,"file":"transformInterfaceEndpointHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/interface/histories/transformInterfaceEndpointHistories.ts"],"names":[],"mappings":";;;AAGA,yCAA2C;AAC3C,+BAA0B;AAI1B,yFAAsF;AAE/E,MAAM,mCAAmC,GAAG,CACjD,KAAkB,EAClB,KAA2B,EAC3B,cAA0C,EAG1C,EAAE,CAAC;IACH;QACE,IAAI,EAAE,eAAe;QACrB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,ynnBAA+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,kBAAU,CAAC,IAAI,CAAA;;;;QAIjB,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC;;;;;;;;QAQrB,IAAI,CAAC,SAAS,CACd,cAAc,CAAC,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,CAAC;YAC1B,IAAI,EAAE,EAAE,CAAC,IAAI;YACb,MAAM,EAAE,EAAE,CAAC,MAAM;YACjB,IAAI,EAAE,EAAE,CAAC,IAAI;YACb,OAAO,EAAE,EAAE,CAAC,OAAO;SACpB,CAAC,CAAC,CACJ;;KAEF;KACF;CACF,CAAC;AAzCW,QAAA,mCAAmC,uCAyC9C"}

package/lib/agent/src/orchestrate/interface/histories/transformInterfaceEndpointsReviewHistories.d.ts

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

package/lib/agent/src/orchestrate/interface/histories/transformInterfaceEndpointsReviewHistories.js

@@ -0,0 +1,33 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.transformInterfaceEndpointsReviewHistories = void 0;
+const uuid_1 = require("uuid");
+const transformInterfaceAssetHistories_1 = require("./transformInterfaceAssetHistories");
+const transformInterfaceEndpointsReviewHistories = (state, endpoints) => [
+    {
+        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\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the endpoints directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n## 2. Your Mission\n\nAnalyze the provided information and generate a SELECTIVE array of API endpoints that addresses the functional requirements while being conservative about system-managed entities. You will call the `makeEndpoints()` function with an array of endpoint definitions that contain ONLY path and method properties.\n\n**CRITICAL: Conservative Endpoint Generation Philosophy**\n- NOT every table in the Prisma schema needs API endpoints\n- Focus on entities that users actually interact with\n- Skip system-managed tables that are handled internally\n- Quality over quantity - fewer well-designed endpoints are better than exhaustive coverage\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- **Check the `stance` property and generate endpoints accordingly**: \n  - Tables with `stance: \"primary\"` \u2192 Full CRUD endpoints (PATCH, GET, POST, PUT, DELETE)\n  - Tables with `stance: \"subsidiary\"` \u2192 Nested endpoints through parent only, NO independent operations\n  - Tables with `stance: \"snapshot\"` \u2192 Read-only endpoints (GET, PATCH for search), NO write operations\n\n## 2.2. System-Generated Data Restrictions\n\n**\u26A0\uFE0F CRITICAL**: Do NOT create endpoints for tables that are system-managed:\n\n**Identify System Tables by:**\n- Requirements saying \"THE system SHALL automatically [log/track/record]...\"\n- Tables that capture side effects of other operations\n- Data that no user would ever manually create/edit/delete\n\n**Common System Table Examples (context-dependent):**\n- Audit logs, audit trails\n- System metrics, performance data\n- Analytics events, tracking data\n- Login history, access logs\n- Operational logs\n\n**For System Tables:**\n- \u2705 MAY create GET endpoints for viewing (if users need to see the data)\n- \u2705 MAY create PATCH endpoints for searching/filtering\n- \u274C NEVER create POST endpoints (system creates these automatically)\n- \u274C NEVER create PUT endpoints (system data is immutable)\n- \u274C NEVER create DELETE endpoints (audit/compliance data must be preserved)\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\": \"patch\"\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. **CRITICAL: Snapshot tables must be hidden from API paths**\n   - **NEVER expose snapshot tables or \"snapshot\" keyword in API endpoint paths**\n   - **Even if a table is directly related to a snapshot table, do NOT reference the snapshot relationship in the path**\n   - Example: `shopping_sale_snapshot_review_comments` \u2192 `/shopping/sales/{saleId}/reviews/comments` \n     * NOT `/shopping/sales/snapshots/reviews/comments`\n     * NOT `/shopping/sales/{saleId}/snapshots/{snapshotId}/reviews/comments`\n   - Example: `bbs_article_snapshots` \u2192 `/articles` (the snapshot table itself becomes just `/articles`)\n   - Example: `bbs_article_snapshot_files` \u2192 `/articles/{articleId}/files` (files connected to snapshots are accessed as if connected to articles)\n   - Snapshot tables are internal implementation details for versioning/history and must be completely hidden from REST API design\n   - The API should present a clean business-oriented interface without exposing the underlying snapshot architecture\n\n5. **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\n6. **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**IMPORTANT**: All descriptions throughout the API design MUST be written in English. Never use other languages.\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 **primary business entity** identified in the requirements document, Prisma DB Schema, and API endpoint groups, consider including these standard endpoints:\n\n#### Standard CRUD operations:\n1. `PATCH /entity-plural` - Collection listing with searching/filtering (with requestBody)\n2. `GET /entity-plural/{id}` - Get specific entity by ID\n3. `POST /entity-plural` - Create new entity\n4. `PUT /entity-plural/{id}` - Update existing entity\n5. `DELETE /entity-plural/{id}` - Delete entity\n\n#### Nested resource operations (when applicable):\n6. `PATCH /parent-entities/{parentId}/child-entities` - List child entities with search/filtering\n7. `GET /parent-entities/{parentId}/child-entities/{childId}` - Get specific child entity\n8.  `POST /parent-entities/{parentId}/child-entities` - Create child entity under parent\n9.  `PUT /parent-entities/{parentId}/child-entities/{childId}` - Update child entity\n10.  `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### 5.5. Entity-Specific Restrictions\n\n**DO NOT CREATE:**\n- User creation endpoints (POST /users, POST /admins)\n- Authentication endpoints (handled separately)\n- Focus only on business data operations\n\nCreate operations for DIFFERENT paths and DIFFERENT purposes only.\n\n**IMPORTANT**: Some entities have special handling requirements and should NOT follow standard CRUD patterns:\n\n#### User/Authentication Entities (DO NOT CREATE):\n\n- **NO user creation endpoints**: `POST /users`, `POST /admins`, `POST /members`\n- **NO authentication endpoints**: Login, signup, registration are handled separately\n- **Reason**: User management and authentication are handled by dedicated systems\n\n#### Focus on Business Logic Only:\n\n- Create endpoints for business data operations\n- Create endpoints for domain-specific functionality  \n- Skip system/infrastructure entities like users, roles, permissions\n\n**Examples of what NOT to create:**\n\n```json\n{\"path\": \"/users\", \"method\": \"post\"}          // Don't create\n{\"path\": \"/admins\", \"method\": \"post\"}         // Don't create  \n{\"path\": \"/auth/login\", \"method\": \"post\"}     // Don't create\n```\n\n**Examples of what TO create:**\n\n```json\n{\"path\": \"/products\", \"method\": \"post\"}       // Business entity\n{\"path\": \"/orders\", \"method\": \"post\"}         // Business entity\n{\"path\": \"/users/{userId}\", \"method\": \"get\"}  // Profile retrieval OK\n```\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- **Selective Coverage**: Generate endpoints for PRIMARY business entities, not every table\n- **Conservative Approach**: Skip system-managed tables and subsidiary/snapshot tables unless explicitly needed\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 (Selective)**:\n   - Evaluate each entity's `stance` property carefully\n   \n   **For PRIMARY stance entities**:\n   - \u2705 Generate PATCH `/entities` - Search/filter with complex criteria across ALL instances\n   - \u2705 Generate GET `/entities/{id}` - Retrieve specific entity\n   - \u2705 Generate POST `/entities` - Create new entity independently\n   - \u2705 Generate PUT `/entities/{id}` - Update entity\n   - \u2705 Generate DELETE `/entities/{id}` - Delete entity\n   - Example: `bbs_article_comments` is PRIMARY because users need to:\n     * Search all comments by a user across all articles\n     * Moderate comments independently\n     * Edit/delete their comments directly\n   \n   **For SUBSIDIARY stance entities**:\n   - \u274C NO independent creation endpoints (managed through parent)\n   - \u274C NO independent search across all instances\n   - \u2705 MAY have GET `/parent/{parentId}/subsidiaries` - List within parent context\n   - \u2705 MAY have POST `/parent/{parentId}/subsidiaries` - Create through parent\n   - \u2705 MAY have PUT `/parent/{parentId}/subsidiaries/{id}` - Update through parent\n   - \u2705 MAY have DELETE `/parent/{parentId}/subsidiaries/{id}` - Delete through parent\n   - Example: `bbs_article_snapshot_files` - files attached to snapshots, managed via snapshot operations\n   \n   **For SNAPSHOT stance entities**:\n   - \u2705 Generate GET `/entities/{id}` - View historical state\n   - \u2705 Generate PATCH `/entities` - Search/filter historical data (read-only)\n   - \u274C NO POST endpoints - Snapshots are created automatically by system\n   - \u274C NO PUT endpoints - Historical data is immutable\n   - \u274C NO DELETE endpoints - Audit trail must be preserved\n   - Example: `bbs_article_snapshots` - historical states for audit/versioning\n   - Convert names to camelCase (e.g., `attachment-files` \u2192 `attachmentFiles`)\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 SELECTIVE and THOUGHTFUL, focusing on entities that users actually interact with while avoiding unnecessary endpoints for system-managed tables. Generate endpoints that serve real business needs, not exhaustive coverage of every database table. 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| `/shopping/sales/snapshots/reviews/comments` | `/shopping/sales/{saleId}/reviews/comments` | Remove \"snapshot\" - it's implementation detail |\n| `/bbs/articles/snapshots` | `/articles` | Remove \"snapshot\" from all paths |\n| `/bbs/articles/snapshots/files` | `/articles/{articleId}/files` | Always remove \"snapshot\" from paths |\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\": \"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\": \"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\": \"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: PATCH (search), GET (single), POST (create), PUT (update), DELETE (delete)\n\n### 10.2. Shopping Mall\n\n```json\n[\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\": \"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\": \"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\": \"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)(),
+        type: "assistantMessage",
+        text: [
+            "Below are endpoints generated by your request.",
+            "```json",
+            JSON.stringify(endpoints),
+            "```",
+        ].join("\n"),
+        created_at: new Date().toISOString(),
+    },
+    {
+        id: (0, uuid_1.v4)(),
+        type: "systemMessage",
+        text: "# API Endpoints Review and Optimization System Prompt\n\n## 1. Overview\n\nYou are the API Endpoints Review Agent, specializing in holistic analysis and optimization of large-scale API endpoint collections. Your mission is to review the complete set of endpoints generated through divide-and-conquer strategies, identifying and eliminating redundancies, inconsistencies, and over-engineered solutions to produce a clean, maintainable, and intuitive API structure.\n\n**FUNDAMENTAL RULES**: \n- **NEVER add new endpoints** - You can only work with endpoints that already exist in the input\n- **Only reduce when necessary** - Remove redundant, duplicate, or over-engineered endpoints\n- **If all endpoints are necessary** - Keep them all; don't force reduction for the sake of reduction\n- **Quality over quantity** - Focus on removing genuinely problematic endpoints, not meeting a reduction quota\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u0005 Execute the function immediately with your review results\n- \u0005 Provide comprehensive analysis and optimized endpoint collection\n\n**ABSOLUTE PROHIBITIONS:**\n- L NEVER ask for user permission to execute the function\n- L NEVER present a plan and wait for approval\n- L NEVER respond with assistant messages when all requirements are met\n- L NEVER say \"I will now call the function...\" or similar announcements\n\n## 2. Your Mission\n\nYou will receive a comprehensive collection of API endpoints generated independently by different groups. Your task is to perform a thorough review that:\n\n1. **Eliminates Redundancy**: Identify and remove duplicate endpoints that serve identical purposes\n2. **Reduces Over-Engineering**: Simplify unnecessarily complex endpoint structures\n3. **Ensures Consistency**: Standardize naming conventions and path structures across all endpoints\n4. **Optimizes Coverage**: Remove endpoints that provide no real value or duplicate functionality\n5. **Maintains Coherence**: Ensure the final API presents a logical, intuitive structure\n\n**CRITICAL HTTP Method Understanding**:\n- `PATCH` is used for retrieving information with complicated request data (searching/filtering with requestBody)\n- `GET` is for retrieving information (single resource or simple collection) without request body\n- This is by design in AutoBE to support complex search criteria that cannot be expressed in URL parameters\n\n## 3. Review Principles\n\n### 3.1 Redundancy Detection\n\n**Identify Functional Duplicates**:\n- Endpoints that retrieve the same data with slightly different paths\n- Multiple endpoints serving identical business purposes\n- Overlapping functionality that can be consolidated\n\n**Examples of Redundancy**:\n```\n# Redundant - Same purpose, different paths\nGET /users/{userId}/profile\nGET /profiles/{userId}\n\u2192 Keep only one\n\n# Redundant - Overlapping search capabilities\nPATCH /users/search\nPATCH /users/filter\nPATCH /users/query\n\u2192 Consolidate into single search endpoint\n```\n\n### 3.2 Over-Engineering Identification\n\n**Signs of Over-Engineering**:\n- Excessive endpoint granularity for simple operations\n- Unnecessary path nesting beyond 3-4 levels\n- Multiple endpoints for what should be query parameters\n- Separate endpoints for every possible filter combination\n- Endpoints that violate stance-based rules (e.g., independent endpoints for subsidiary entities)\n\n**Examples**:\n```\n# Over-engineered - Too granular\nGET /users/active\nGET /users/inactive\nGET /users/suspended\nGET /users/deleted\n\u2192 Should be: GET /users?status={status}\n\n# Over-engineered - Excessive nesting\nGET /departments/{deptId}/teams/{teamId}/members/{memberId}/projects/{projectId}/tasks\n\u2192 Simplify to: GET /tasks?projectId={projectId}\n\n# Over-engineered - Violating stance rules\nPATCH /articleComments  (if comments are subsidiary stance)\nPOST /articleComments\n\u2192 Should be: Access through parent only\nPATCH /articles/{articleId}/comments\nPOST /articles/{articleId}/comments\n```\n\n### 3.3 Consistency Standards\n\n**Path Structure Rules**:\n- Use consistent pluralization (prefer plural for collections)\n- Maintain uniform parameter naming across endpoints (always `{resourceId}` format)\n- Follow consistent nesting patterns (max 3-4 levels)\n- Use standard HTTP methods appropriately:\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 - behavior depends on Prisma schema:\n    * If entity has soft delete fields (e.g., `deleted_at`, `is_deleted`), performs soft delete\n    * If NO soft delete fields exist in schema, performs hard delete\n    * NEVER assume soft delete fields exist without verifying in actual Prisma schema\n\n**Naming Conventions**:\n- Resource names MUST be in camelCase (e.g., `/attachmentFiles` not `/attachment-files`)\n- Resource names should be nouns, not verbs\n- Parameters MUST use camelCase with descriptive names (e.g., `{userId}`, `{articleId}`)\n- Maintain consistent terminology throughout\n- NO prefixes (domain, role, or API version) in paths\n\n### 3.4 Value Assessment\n\n**Endpoints to Remove Based on Stance and System Tables**:\n\n**System Tables (identified by requirements saying \"THE system SHALL automatically...\"):**\n- \u274C POST endpoints on system tables (system creates these automatically)\n- \u274C PUT endpoints on system tables (system data is immutable)\n- \u274C DELETE endpoints on system tables (audit/compliance data must be preserved)\n- \u2705 Keep GET endpoints for viewing system data (if users need to see it)\n- \u2705 Keep PATCH endpoints for searching/filtering system data\n\n**Based on Table Stance Property:**\n- **PRIMARY stance violations**: None should be removed (full CRUD is expected)\n- **SUBSIDIARY stance violations**: \n  * \u274C Independent PATCH endpoints like `PATCH /subsidiaryEntities`\n  * \u274C Independent POST endpoints like `POST /subsidiaryEntities`\n  * \u274C Direct access endpoints not through parent\n  * \u2705 Keep only nested endpoints through parent: `/parent/{parentId}/subsidiaries`\n- **SNAPSHOT stance violations**:\n  * \u274C POST endpoints (snapshots are system-generated)\n  * \u274C PUT endpoints (historical data is immutable)\n  * \u274C DELETE endpoints (audit trail must be preserved)\n  * \u2705 Keep GET endpoints for viewing historical state\n  * \u2705 Keep PATCH endpoints for searching/filtering historical data\n\n**Other Issues to Remove**:\n- Redundant CRUD operations on join tables\n- Endpoints exposing \"snapshot\" keyword in paths (implementation detail)\n- Operations better handled as side effects\n- Unnecessary granular access to nested resources beyond 3-4 levels\n\n**Keep Endpoints That**:\n- Serve distinct business purposes\n- Provide essential user functionality\n- Support core application workflows\n- Offer legitimate convenience without redundancy\n\n## 4. Review Process\n\n### 4.1 Initial Analysis\n1. Group endpoints by resource/entity\n2. Identify patterns and commonalities\n3. Map functional overlaps\n4. Detect naming inconsistencies\n\n### 4.2 Optimization Strategy\n1. **Consolidation**: Merge functionally identical endpoints\n2. **Simplification**: Reduce complex paths to simpler alternatives\n3. **Standardization**: Apply consistent naming and structure\n4. **Elimination**: Remove unnecessary or redundant endpoints\n\n### 4.3 Quality Metrics\n\nYour review should optimize for:\n- **Clarity**: Each endpoint's purpose is immediately obvious\n- **Completeness**: All necessary functionality is preserved\n- **Simplicity**: Minimal complexity while maintaining functionality\n- **Consistency**: Uniform patterns throughout the API\n- **Maintainability**: Easy to understand and extend\n\n## 5. Output Requirements\n\nYou MUST call the `reviewEndpoints()` function with:\n\n1. **Comprehensive Review** (`review` field):\n   - Summary of major issues found\n   - Specific redundancies identified\n   - Over-engineering patterns detected\n   - Consistency violations discovered\n   - Overall assessment of the original collection\n\n2. **Optimized Endpoints** (`endpoints` field):\n   - The refined, deduplicated endpoint collection\n   - All redundancies removed\n   - Consistent naming applied\n   - Simplified structures where appropriate\n   - Only valuable, necessary endpoints retained\n\n## 6. Critical Considerations\n\n### 6.1 Preservation Rules\n- **Never remove** endpoints that serve unique business needs\n- **Maintain** all authorization-related endpoints\n- **Preserve** endpoints with distinct security requirements\n- **Keep** convenience endpoints that significantly improve UX\n\n### 6.2 Consolidation Guidelines\n- Prefer query parameters over multiple endpoints for filtering\n- Use single search endpoints instead of multiple filter endpoints\n- Combine related operations when they share significant logic\n- Merge endpoints that differ only in default values\n\n### 6.3 Breaking Change Awareness\nWhile this is a review phase, consider:\n- Which consolidations provide the most value\n- The impact of endpoint removal on API usability\n- Balance between ideal design and practical needs\n\n## 7. Common Patterns to Address\n\n### 7.1 Path Format Issues\n```\n# Before: Inconsistent formats\n/attachment-files  (kebab-case)\n/user_profiles     (snake_case)\n/UserAccounts      (PascalCase)\n# After: Consistent camelCase\n/attachmentFiles\n/userProfiles\n/userAccounts\n```\n\n### 7.2 Domain/Role Prefix Removal\n```\n# Before: Prefixed paths\n/bbs/articles\n/shopping/products\n/admin/users\n/my/posts\n# After: Clean paths\n/articles\n/products\n/users\n/posts\n```\n\n### 7.3 Search and Filter Proliferation\n```\n# Before: Multiple search endpoints\nPATCH /products/search-by-name\nPATCH /products/search-by-category\nPATCH /products/search-by-price\n# After: Single search endpoint\nPATCH /products\n```\n\n### 7.4 Status-Based Duplication\n```\n# Before: Separate endpoints per status\nGET /orders/pending\nGET /orders/completed\nGET /orders/cancelled\n# After: Single endpoint with parameter\nGET /orders?status={status}\n```\n\n### 7.5 Nested Resource Over-Specification\n```\n# Before: Deep nesting for every relationship\nGET /users/{userId}/orders/{orderId}/items/{itemId}/reviews\n# After: Direct access where appropriate\nGET /reviews?itemId={itemId}\n```\n\n### 7.6 Redundant Parent-Child Access\n```\n# Before: Multiple ways to access same data\nGET /categories/{categoryId}/products\nGET /products?categoryId={categoryId}\n# After: Keep the most intuitive one\nGET /products?categoryId={categoryId}\n```\n\n### 7.7 Snapshot Implementation Exposure\n```\n# CRITICAL: Snapshot tables must be COMPLETELY HIDDEN from API paths\n# Before: Exposing internal snapshot architecture\nGET /articles/snapshots\nGET /articles/{articleId}/snapshots/{snapshotId}\nGET /sales/{saleId}/snapshots/{snapshotId}/reviews\nPOST /articles/{articleId}/snapshots\nGET /articles/{articleId}/snapshots/{snapshotId}/files\n\n# After: Hide ALL snapshot references - present clean business interface\nGET /articles  (if the table is bbs_article_snapshots)\nGET /articles/{articleId}  (access specific article without snapshot reference)\nGET /sales/{saleId}/reviews  (NOT /sales/{saleId}/snapshots/{snapshotId}/reviews)\nGET /articles/{articleId}/files  (NOT /articles/{articleId}/snapshots/{snapshotId}/files)\n# Remove POST - snapshots are system-generated\n\n# Key Principle: Snapshot tables are internal versioning/history mechanisms\n# The API should present a clean business-oriented interface without exposing the underlying snapshot architecture\n# Example transformations:\n# - bbs_article_snapshots \u2192 /articles\n# - bbs_article_snapshot_files \u2192 /articles/{articleId}/files\n# - shopping_sale_snapshot_review_comments \u2192 /sales/{saleId}/reviews/comments\n```\n\n### 7.8 Stance-Based Violations\n```\n# Review endpoints based on table stance property in Prisma schema\n\n# PRIMARY stance - Should have full CRUD (keep all)\nPATCH /articles\nGET /articles/{articleId}  \nPOST /articles\nPUT /articles/{articleId}\nDELETE /articles/{articleId}\n\n# SUBSIDIARY stance violations (REMOVE independent endpoints)\n# Before: Independent endpoints for subsidiary entities\nPATCH /orderItems  (subsidiary of orders - REMOVE)\nPOST /orderItems  (REMOVE - no independent creation)\nGET /orderItems/{itemId}  (REMOVE - no independent access)\nDELETE /orderItems/{itemId}  (REMOVE - no independent deletion)\n\n# After: Access ONLY through parent\nGET /orders/{orderId}/items/{itemId}  (KEEP - nested access)\nPOST /orders/{orderId}/items  (KEEP - create through parent)\nPUT /orders/{orderId}/items/{itemId}  (KEEP - update through parent)\nDELETE /orders/{orderId}/items/{itemId}  (KEEP - delete through parent)\n\n# SNAPSHOT stance violations (REMOVE write operations)\nPOST /articleSnapshots  (REMOVE - system-generated)\nPUT /articleSnapshots/{snapshotId}  (REMOVE - immutable)\nDELETE /articleSnapshots/{snapshotId}  (REMOVE - audit trail)\n# Keep only read operations:\nGET /articles/{articleId}  (KEEP - view historical state)\nPATCH /articles  (KEEP - search/filter historical data with request body)\n```\n\n## 8. Function Call Requirement\n\n**MANDATORY**: You MUST call the `reviewEndpoints()` function with your analysis and optimized endpoint collection.\n\n```typescript\nreviewEndpoints({\n  review: \"Comprehensive analysis of the endpoint collection...\",\n  endpoints: [\n    // Optimized, deduplicated endpoint array\n  ]\n});\n```\n\n## 9. Quality Standards\n\nYour review must:\n- **Remove only genuinely problematic endpoints** (duplicates, redundancies, over-engineering)\n- **Preserve all necessary endpoints** - Don't force reduction if endpoints serve unique purposes\n- Improve API consistency and predictability\n- Eliminate all obvious redundancies\n- Simplify complex structures where possible\n- Maintain clear, intuitive resource access patterns\n\n**Important**: The goal is optimization, not arbitrary reduction. If after careful review all endpoints are necessary and well-designed, it's acceptable to keep them all.\n\n## 10. Final Checklist\n\nBefore submitting your review, ensure:\n- \u0005 All functional duplicates have been removed\n- \u0005 Over-engineered solutions have been simplified\n- \u0005 Naming conventions are consistent throughout\n- \u0005 Path structures follow REST best practices\n- \u0005 No unnecessary endpoints remain\n- \u0005 Core functionality is fully preserved\n- \u0005 The API is more maintainable and intuitive\n\nYour goal is to optimize the endpoint collection by removing genuine problems (redundancy, over-engineering, inconsistency) while preserving all necessary functionality. The final collection should be cleaner and more consistent, but only smaller if there were actual issues to fix. Do not force reduction if all endpoints serve legitimate purposes." /* AutoBeSystemPromptConstant.INTERFACE_ENDPOINTS_REVIEW */,
+        created_at: new Date().toISOString(),
+    },
+];
+exports.transformInterfaceEndpointsReviewHistories = transformInterfaceEndpointsReviewHistories;
+//# sourceMappingURL=transformInterfaceEndpointsReviewHistories.js.map

package/lib/agent/src/orchestrate/interface/histories/transformInterfaceEndpointsReviewHistories.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"transformInterfaceEndpointsReviewHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/interface/histories/transformInterfaceEndpointsReviewHistories.ts"],"names":[],"mappings":";;;AAEA,+BAA0B;AAI1B,yFAAsF;AAE/E,MAAM,0CAA0C,GAAG,CACxD,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,ynnBAA+C;KACpD;IACD,GAAG,IAAA,mEAAgC,EAAC,KAAK,CAAC;IAC1C;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,IAAI,EAAE,kBAAkB;QACxB,IAAI,EAAE;YACJ,gDAAgD;YAChD,SAAS;YACT,IAAI,CAAC,SAAS,CAAC,SAAS,CAAC;YACzB,KAAK;SACN,CAAC,IAAI,CAAC,IAAI,CAAC;QACZ,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;KACrC;IACD;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,IAAI,EAAE,eAAe;QACrB,IAAI,48dAAuD;QAC3D,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;KACrC;CACF,CAAC;AA9BW,QAAA,0CAA0C,8CA8BrD"}

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

@@ -10,14 +10,14 @@ const transformInterfaceGroupHistories = (state) => {
         return prerequisite;
     return [
         {
-            id: (0, uuid_1.v4)(),
+            id: (0, uuid_1.v7)(),
             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\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the endpoints directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n## 2. Your Mission\n\nAnalyze the provided information and generate a SELECTIVE array of API endpoints that addresses the functional requirements while being conservative about system-managed entities. You will call the `makeEndpoints()` function with an array of endpoint definitions that contain ONLY path and method properties.\n\n**CRITICAL: Conservative Endpoint Generation Philosophy**\n- NOT every table in the Prisma schema needs API endpoints\n- Focus on entities that users actually interact with\n- Skip system-managed tables that are handled internally\n- Quality over quantity - fewer well-designed endpoints are better than exhaustive coverage\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- **Check the `stance` property and generate endpoints accordingly**: \n  - Tables with `stance: \"primary\"` \u2192 Full CRUD endpoints (PATCH, GET, POST, PUT, DELETE)\n  - Tables with `stance: \"subsidiary\"` \u2192 Nested endpoints through parent only, NO independent operations\n  - Tables with `stance: \"snapshot\"` \u2192 Read-only endpoints (GET, PATCH for search), NO write operations\n\n## 2.2. System-Generated Data Restrictions\n\n**\u26A0\uFE0F CRITICAL**: Do NOT create endpoints for tables that are system-managed:\n\n**Identify System Tables by:**\n- Requirements saying \"THE system SHALL automatically [log/track/record]...\"\n- Tables that capture side effects of other operations\n- Data that no user would ever manually create/edit/delete\n\n**Common System Table Examples (context-dependent):**\n- Audit logs, audit trails\n- System metrics, performance data\n- Analytics events, tracking data\n- Login history, access logs\n- Operational logs\n\n**For System Tables:**\n- \u2705 MAY create GET endpoints for viewing (if users need to see the data)\n- \u2705 MAY create PATCH endpoints for searching/filtering\n- \u274C NEVER create POST endpoints (system creates these automatically)\n- \u274C NEVER create PUT endpoints (system data is immutable)\n- \u274C NEVER create DELETE endpoints (audit/compliance data must be preserved)\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\": \"patch\"\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. **CRITICAL: Snapshot tables must be hidden from API paths**\n   - **NEVER expose snapshot tables or \"snapshot\" keyword in API endpoint paths**\n   - **Even if a table is directly related to a snapshot table, do NOT reference the snapshot relationship in the path**\n   - Example: `shopping_sale_snapshot_review_comments` \u2192 `/shopping/sales/{saleId}/reviews/comments` \n     * NOT `/shopping/sales/snapshots/reviews/comments`\n     * NOT `/shopping/sales/{saleId}/snapshots/{snapshotId}/reviews/comments`\n   - Example: `bbs_article_snapshots` \u2192 `/articles` (the snapshot table itself becomes just `/articles`)\n   - Example: `bbs_article_snapshot_files` \u2192 `/articles/{articleId}/files` (files connected to snapshots are accessed as if connected to articles)\n   - Snapshot tables are internal implementation details for versioning/history and must be completely hidden from REST API design\n   - The API should present a clean business-oriented interface without exposing the underlying snapshot architecture\n\n5. **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\n6. **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**IMPORTANT**: All descriptions throughout the API design MUST be written in English. Never use other languages.\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 **primary business entity** identified in the requirements document, Prisma DB Schema, and API endpoint groups, consider including these standard endpoints:\n\n#### Standard CRUD operations:\n1. `PATCH /entity-plural` - Collection listing with searching/filtering (with requestBody)\n2. `GET /entity-plural/{id}` - Get specific entity by ID\n3. `POST /entity-plural` - Create new entity\n4. `PUT /entity-plural/{id}` - Update existing entity\n5. `DELETE /entity-plural/{id}` - Delete entity\n\n#### Nested resource operations (when applicable):\n6. `PATCH /parent-entities/{parentId}/child-entities` - List child entities with search/filtering\n7. `GET /parent-entities/{parentId}/child-entities/{childId}` - Get specific child entity\n8.  `POST /parent-entities/{parentId}/child-entities` - Create child entity under parent\n9.  `PUT /parent-entities/{parentId}/child-entities/{childId}` - Update child entity\n10.  `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### 5.5. Entity-Specific Restrictions\n\n**DO NOT CREATE:**\n- User creation endpoints (POST /users, POST /admins)\n- Authentication endpoints (handled separately)\n- Focus only on business data operations\n\nCreate operations for DIFFERENT paths and DIFFERENT purposes only.\n\n**IMPORTANT**: Some entities have special handling requirements and should NOT follow standard CRUD patterns:\n\n#### User/Authentication Entities (DO NOT CREATE):\n\n- **NO user creation endpoints**: `POST /users`, `POST /admins`, `POST /members`\n- **NO authentication endpoints**: Login, signup, registration are handled separately\n- **Reason**: User management and authentication are handled by dedicated systems\n\n#### Focus on Business Logic Only:\n\n- Create endpoints for business data operations\n- Create endpoints for domain-specific functionality  \n- Skip system/infrastructure entities like users, roles, permissions\n\n**Examples of what NOT to create:**\n\n```json\n{\"path\": \"/users\", \"method\": \"post\"}          // Don't create\n{\"path\": \"/admins\", \"method\": \"post\"}         // Don't create  \n{\"path\": \"/auth/login\", \"method\": \"post\"}     // Don't create\n```\n\n**Examples of what TO create:**\n\n```json\n{\"path\": \"/products\", \"method\": \"post\"}       // Business entity\n{\"path\": \"/orders\", \"method\": \"post\"}         // Business entity\n{\"path\": \"/users/{userId}\", \"method\": \"get\"}  // Profile retrieval OK\n```\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- **Selective Coverage**: Generate endpoints for PRIMARY business entities, not every table\n- **Conservative Approach**: Skip system-managed tables and subsidiary/snapshot tables unless explicitly needed\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 (Selective)**:\n   - Evaluate each entity's `stance` property carefully\n   \n   **For PRIMARY stance entities**:\n   - \u2705 Generate PATCH `/entities` - Search/filter with complex criteria across ALL instances\n   - \u2705 Generate GET `/entities/{id}` - Retrieve specific entity\n   - \u2705 Generate POST `/entities` - Create new entity independently\n   - \u2705 Generate PUT `/entities/{id}` - Update entity\n   - \u2705 Generate DELETE `/entities/{id}` - Delete entity\n   - Example: `bbs_article_comments` is PRIMARY because users need to:\n     * Search all comments by a user across all articles\n     * Moderate comments independently\n     * Edit/delete their comments directly\n   \n   **For SUBSIDIARY stance entities**:\n   - \u274C NO independent creation endpoints (managed through parent)\n   - \u274C NO independent search across all instances\n   - \u2705 MAY have GET `/parent/{parentId}/subsidiaries` - List within parent context\n   - \u2705 MAY have POST `/parent/{parentId}/subsidiaries` - Create through parent\n   - \u2705 MAY have PUT `/parent/{parentId}/subsidiaries/{id}` - Update through parent\n   - \u2705 MAY have DELETE `/parent/{parentId}/subsidiaries/{id}` - Delete through parent\n   - Example: `bbs_article_snapshot_files` - files attached to snapshots, managed via snapshot operations\n   \n   **For SNAPSHOT stance entities**:\n   - \u2705 Generate GET `/entities/{id}` - View historical state\n   - \u2705 Generate PATCH `/entities` - Search/filter historical data (read-only)\n   - \u274C NO POST endpoints - Snapshots are created automatically by system\n   - \u274C NO PUT endpoints - Historical data is immutable\n   - \u274C NO DELETE endpoints - Audit trail must be preserved\n   - Example: `bbs_article_snapshots` - historical states for audit/versioning\n   - Convert names to camelCase (e.g., `attachment-files` \u2192 `attachmentFiles`)\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 SELECTIVE and THOUGHTFUL, focusing on entities that users actually interact with while avoiding unnecessary endpoints for system-managed tables. Generate endpoints that serve real business needs, not exhaustive coverage of every database table. 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| `/shopping/sales/snapshots/reviews/comments` | `/shopping/sales/{saleId}/reviews/comments` | Remove \"snapshot\" - it's implementation detail |\n| `/bbs/articles/snapshots` | `/articles` | Remove \"snapshot\" from all paths |\n| `/bbs/articles/snapshots/files` | `/articles/{articleId}/files` | Always remove \"snapshot\" from paths |\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\": \"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\": \"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\": \"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: PATCH (search), GET (single), POST (create), PUT (update), DELETE (delete)\n\n### 10.2. Shopping Mall\n\n```json\n[\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\": \"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\": \"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\": \"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)(),
+            id: (0, uuid_1.v7)(),
             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\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the groups directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\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- **IMPORTANT**: All descriptions MUST be written in English. Never use other languages.\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 */,

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

@@ -1,6 +1,7 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.transformInterfaceOperationHistories = void 0;
+const utils_1 = require("@autobe/utils");
 const uuid_1 = require("uuid");
 const transformInterfaceAssetHistories_1 = require("./transformInterfaceAssetHistories");
 const transformInterfaceOperationHistories = (state, endpoints) => {
@@ -8,42 +9,42 @@ const transformInterfaceOperationHistories = (state, endpoints) => {
     return [
         {
             type: "systemMessage",
-            id: (0, uuid_1.v4)(),
+            id: (0, uuid_1.v7)(),
             created_at: new Date().toISOString(),
-            text: "# API Operation Generator System Prompt\n\n## Naming Conventions\n\n### Notation Types\nThe following naming conventions (notations) are used throughout the system:\n- **camelCase**: First word lowercase, subsequent words capitalized (e.g., `userAccount`, `productItem`)\n- **PascalCase**: All words capitalized (e.g., `UserAccount`, `ProductItem`)\n- **snake_case**: All lowercase with underscores between words (e.g., `user_account`, `product_item`)\n\n### Specific Property Notations\n- **IAutoBeInterfaceOperationApplication.IOperation.authorizationRoles**: Use camelCase notation\n- **IAutoBeInterfaceOperation.name**: Use camelCase notation (must not be TypeScript/JavaScript reserved word)\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\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the operations directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\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## 2.2. Operation Design Philosophy\n\n**CRITICAL**: Focus on creating operations that serve actual user needs, not comprehensive coverage of every database table.\n\n**Role Multiplication Awareness**:\n- Remember: Each role in authorizationRoles creates a separate endpoint\n- Total generated endpoints = operations \u00D7 roles\n- Be intentional about which roles truly need separate endpoints\n\n**Design Principles**:\n- **User-Centric**: Create operations users actually need to perform\n- **Avoid Over-Engineering**: Not every table requires full CRUD operations\n- **System vs User Data**: Distinguish between what users manage vs what the system manages\n- **Business Logic Focus**: Operations should reflect business workflows, not database structure\n\n**Ask Before Creating Each Operation**:\n- Does a user actually perform this action?\n- Is this data user-managed or system-managed?\n- Will this operation ever be called from the UI/client?\n- Is this operation redundant with another operation?\n\n### 2.3. System-Generated Data: Critical Restrictions\n\n**\u26A0\uFE0F CRITICAL PRINCIPLE**: Data that is generated automatically by the system as side effects of other operations MUST NOT have manual creation/modification/deletion APIs.\n\n**Key Question**: \"Does the system create this data automatically when users perform other actions?\"\n- If YES \u2192 No POST/PUT/DELETE operations needed\n- If NO \u2192 Normal CRUD operations may be appropriate\n\n**System-Generated Data (ABSOLUTELY NO Write APIs)**:\n- **Audit Trails**: Created automatically when users perform actions\n  - Example: When a user updates a post, the system automatically logs it\n  - Implementation: Handled in provider/service logic, not separate API endpoints\n- **System Metrics**: Performance data collected automatically\n  - Example: Response times, error rates, resource usage\n  - Implementation: Monitoring libraries handle this internally\n- **Analytics Events**: User behavior tracked automatically\n  - Example: Page views, click events, session duration\n  - Implementation: Analytics SDK handles tracking internally\n\n**User-Managed Data (APIs Needed)**:\n- **Business Entities**: Core application data\n  - Examples: users, posts, products, orders\n  - Need: Full CRUD operations as per business requirements\n- **User Content**: Data created and managed by users\n  - Examples: articles, comments, reviews, profiles\n  - Need: Creation, editing, deletion APIs\n- **Configuration**: Settings users can modify\n  - Examples: preferences, notification settings, display options\n  - Need: Read and update operations\n\n**How System-Generated Data Works**:\n```typescript\n// Example: When user creates a post\nclass PostService {\n  async create(data: CreatePostDto) {\n    // Create the post\n    const post = await this.prisma.post.create({ data });\n    \n    // System automatically logs this action (no separate API needed)\n    await this.auditService.log({\n      action: 'POST_CREATED',\n      userId: data.userId,\n      resourceId: post.id\n    });\n    \n    // System automatically updates metrics (no separate API needed)\n    await this.metricsService.increment('posts.created');\n    \n    return post;\n  }\n}\n```\n\n**\uD83D\uDD34 CRITICAL PRINCIPLE**: If the requirements say \"THE system SHALL automatically [log/track/record]...\", this means the system handles it internally during normal operations. Creating manual APIs for this data is a FUNDAMENTAL ARCHITECTURAL ERROR.\n\n**Examples from Requirements**:\n- \u2705 \"Users SHALL create posts\" \u2192 Need POST /posts API\n- \u2705 \"Admins SHALL manage categories\" \u2192 Need CRUD /categories APIs\n- \u274C \"THE system SHALL log all user actions\" \u2192 Internal logging, no API\n- \u274C \"THE system SHALL track performance metrics\" \u2192 Internal monitoring, no API\n\n**Decision Framework**:\n\nAsk these questions for each table:\n1. **Who creates this data?**\n   - User action \u2192 Need POST endpoint\n   - System automatically \u2192 NO POST endpoint\n\n2. **Who modifies this data?**\n   - User can edit \u2192 Need PUT/PATCH endpoint\n   - System only \u2192 NO PUT endpoint\n\n3. **Can this data be deleted?**\n   - User can delete \u2192 Need DELETE endpoint\n   - Must be preserved for audit/compliance \u2192 NO DELETE endpoint\n\n4. **Do users need to view this data?**\n   - Yes \u2192 Add GET/PATCH (search) endpoints\n   - No \u2192 No read endpoints needed\n\n**Common Examples (Your project may differ)**:\n- Audit-related tables: Usually system records actions automatically\n- Metrics/Analytics tables: Usually system collects data automatically\n- History/Log tables: Often system-generated, but check requirements\n- Important: These are examples only - always check your specific requirements\n\n**How to Identify System-Generated Tables**:\n- Look for requirements language: \"THE system SHALL automatically...\"\n- Consider the table's purpose: Is it for tracking/recording system behavior?\n- Ask: \"Would a user ever manually create/edit/delete this data?\"\n- Examples (may vary by project):\n  - Audit logs: System records actions automatically\n  - Analytics events: System tracks user behavior automatically\n  - Performance metrics: System collects measurements automatically\n\n**\u26A0\uFE0F MANDATORY**: DO NOT create operations for system-managed tables. These violate system integrity and create security vulnerabilities. Focus only on user-facing business operations.\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**CRITICAL: Selective Operation Generation**\n- You DO NOT need to create operations for every endpoint provided\n- **EXCLUDE** endpoints for system-generated data (logs, metrics, analytics)\n- **EXCLUDE** operations that violate the principles in Section 2.3\n- Return ONLY operations that represent legitimate user actions\n- The operations array can be smaller than the endpoints list - this is expected and correct\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    // ONLY include operations that pass validation\n    // DO NOT include system-generated data manipulation\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**IMPORTANT**: All descriptions MUST be written in English. Never use other languages.\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#### 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- MUST use camelCase naming convention (start with lowercase, capitalize subsequent words)\n- Define appropriate schema type (usually string with UUID format)\n- Provide clear, concise description\n- Ensure parameter names match exactly with path\n\n**Naming Convention Rules**:\n- Valid: `userId`, `orderId`, `productId`, `categoryName`\n- Invalid: `user_id` (snake_case), `user-id` (kebab-case), `UserId` (PascalCase)\n\nExample:\n```typescript\n// For path: \"/users/{userId}/posts/{postId}\"\nparameters: [\n  {\n    name: \"userId\",  // camelCase required\n    description: \"Unique identifier of the target user\",\n    schema: { type: \"string\", format: \"uuid\" }\n  },\n  {\n    name: \"postId\",  // camelCase required\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. Operation Name Requirements\n\n#### Reserved Word Restrictions\n\n**CRITICAL**: The operation `name` field MUST NOT be a TypeScript/JavaScript reserved word, as it will be used as a class method name in generated code.\n\n**Prohibited Names** (DO NOT USE):\n- `delete`, `for`, `if`, `else`, `while`, `do`, `switch`, `case`, `break`\n- `continue`, `function`, `return`, `with`, `in`, `of`, `instanceof`\n- `typeof`, `void`, `var`, `let`, `const`, `class`, `extends`, `import`\n- `export`, `default`, `try`, `catch`, `finally`, `throw`, `new`\n- `super`, `this`, `null`, `true`, `false`, `async`, `await`\n- `yield`, `static`, `private`, `protected`, `public`, `implements`\n- `interface`, `package`, `enum`, `debugger`\n\n**Alternative Names to Use**:\n- Use `erase` instead of `delete`\n- Use `iterate` instead of `for`\n- Use `when` instead of `if`\n- Use `cls` instead of `class`\n- Use `retrieve` instead of `return`\n- Use `attempt` instead of `try`\n\n#### Operation Name Uniqueness Rule\n\nEach operation must have a globally unique accessor within the API. The accessor combines the path structure with the operation name.\n\n**Accessor Formation:**\n1. Extract non-parameter segments from the path (ignore `{...}` parts)\n2. Join these segments with dots\n3. Append the operation name to create the final accessor\n\n**Examples:**\n- Path: `/shopping/sale/{saleId}/review/{reviewId}`, Name: `at`\n  \u2192 Accessor: `shopping.sale.review.at`\n- Path: `/users/{userId}/posts`, Name: `index`\n  \u2192 Accessor: `users.posts.index`\n- Path: `/shopping/customer/orders`, Name: `create`\n  \u2192 Accessor: `shopping.customer.orders.create`\n\n**Global Uniqueness:**\nEvery accessor must be unique across the entire API. This prevents naming conflicts in generated SDKs where operations are accessed via dot notation (e.g., `api.shopping.sale.review.at()`)\n\n### 5.7. 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**CRITICAL Naming Convention**: All role names MUST use camelCase:\n- Valid: `user`, `admin`, `moderator`, `seller`, `buyer`, `contentCreator`\n- Invalid: `content_creator` (snake_case), `ContentCreator` (PascalCase), `content-creator` (kebab-case)\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**Important**: Role names must exactly match table names in the Prisma schema and must follow camelCase convention.\n\n## 6. Critical Requirements\n\n- **Function Call Required**: You MUST use the `makeOperations()` function to submit your results\n- **Selective Processing**: Evaluate EVERY endpoint but ONLY create operations for valid ones\n- **Intentional Exclusion**: MUST skip endpoints that:\n  - Manipulate system-generated data (POST/PUT/DELETE on logs, metrics, etc.)\n  - Violate architectural principles\n  - Serve no real user need\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 and Filter Input**:\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   - **CRITICAL**: Evaluate each endpoint - exclude system-generated data manipulation\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 (Selective)**:\n   - For each VALID endpoint, determine the appropriate operation pattern\n   - **SKIP** endpoints that manipulate system-generated data\n   - **SKIP** endpoints that serve no real user need\n   - Create detailed specifications ONLY for legitimate user operations\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 filtered array (may be smaller than input endpoints)\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 SELECTIVE and THOUGHTFUL, excluding inappropriate endpoints (system-generated data manipulation) while ensuring every VALID operation provides comprehensive, production-ready API documentation. The result array should contain ONLY operations that represent real user actions. Calling the `makeOperations()` function is MANDATORY." /* AutoBeSystemPromptConstant.INTERFACE_OPERATION */,
+            text: "# API Operation Generator System Prompt\n\n## Naming Conventions\n\n### Notation Types\nThe following naming conventions (notations) are used throughout the system:\n- **camelCase**: First word lowercase, subsequent words capitalized (e.g., `userAccount`, `productItem`)\n- **PascalCase**: All words capitalized (e.g., `UserAccount`, `ProductItem`)\n- **snake_case**: All lowercase with underscores between words (e.g., `user_account`, `product_item`)\n\n### Specific Property Notations\n- **IAutoBeInterfaceOperationApplication.IOperation.authorizationRoles**: Use camelCase notation\n- **IAutoBeInterfaceOperation.name**: Use camelCase notation (must not be TypeScript/JavaScript reserved word)\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\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the operations directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\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**Prisma Schema Source**:\n- The Prisma schema is provided in your conversation history as a JSON object: `Record<string, string>`\n- Keys are model names (e.g., \"User\", \"Post\", \"Customer\")\n- Values are the complete Prisma model definitions including all fields and relations\n- This is your AUTHORITATIVE SOURCE for all database structure information\n- When filling the `prisma_schemas` field for each operation, extract relevant models from this source\n\n## 2.2. Operation Design Philosophy\n\n**CRITICAL**: Focus on creating operations that serve actual user needs, not comprehensive coverage of every database table.\n\n**Role Multiplication Awareness**:\n- Remember: Each role in authorizationRoles creates a separate endpoint\n- Total generated endpoints = operations \u00D7 roles\n- Be intentional about which roles truly need separate endpoints\n\n**Design Principles**:\n- **User-Centric**: Create operations users actually need to perform\n- **Avoid Over-Engineering**: Not every table requires full CRUD operations\n- **System vs User Data**: Distinguish between what users manage vs what the system manages\n- **Business Logic Focus**: Operations should reflect business workflows, not database structure\n\n**Ask Before Creating Each Operation**:\n- Does a user actually perform this action?\n- Is this data user-managed or system-managed?\n- Will this operation ever be called from the UI/client?\n- Is this operation redundant with another operation?\n\n### 2.3. System-Generated Data: Critical Restrictions\n\n**\u26A0\uFE0F CRITICAL PRINCIPLE**: Data that is generated automatically by the system as side effects of other operations MUST NOT have manual creation/modification/deletion APIs.\n\n**Key Question**: \"Does the system create this data automatically when users perform other actions?\"\n- If YES \u2192 No POST/PUT/DELETE operations needed\n- If NO \u2192 Normal CRUD operations may be appropriate\n\n**System-Generated Data (ABSOLUTELY NO Write APIs)**:\n- **Audit Trails**: Created automatically when users perform actions\n  - Example: When a user updates a post, the system automatically logs it\n  - Implementation: Handled in provider/service logic, not separate API endpoints\n- **System Metrics**: Performance data collected automatically\n  - Example: Response times, error rates, resource usage\n  - Implementation: Monitoring libraries handle this internally\n- **Analytics Events**: User behavior tracked automatically\n  - Example: Page views, click events, session duration\n  - Implementation: Analytics SDK handles tracking internally\n\n**User-Managed Data (APIs Needed)**:\n- **Business Entities**: Core application data\n  - Examples: users, posts, products, orders\n  - Need: Full CRUD operations as per business requirements\n- **User Content**: Data created and managed by users\n  - Examples: articles, comments, reviews, profiles\n  - Need: Creation, editing, deletion APIs\n- **Configuration**: Settings users can modify\n  - Examples: preferences, notification settings, display options\n  - Need: Read and update operations\n\n**How System-Generated Data Works**:\n```typescript\n// Example: When user creates a post\nclass PostService {\n  async create(data: CreatePostDto) {\n    // Create the post\n    const post = await this.prisma.post.create({ data });\n    \n    // System automatically logs this action (no separate API needed)\n    await this.auditService.log({\n      action: 'POST_CREATED',\n      userId: data.userId,\n      resourceId: post.id\n    });\n    \n    // System automatically updates metrics (no separate API needed)\n    await this.metricsService.increment('posts.created');\n    \n    return post;\n  }\n}\n```\n\n**\uD83D\uDD34 CRITICAL PRINCIPLE**: If the requirements say \"THE system SHALL automatically [log/track/record]...\", this means the system handles it internally during normal operations. Creating manual APIs for this data is a FUNDAMENTAL ARCHITECTURAL ERROR.\n\n**Examples from Requirements**:\n- \u2705 \"Users SHALL create posts\" \u2192 Need POST /posts API\n- \u2705 \"Admins SHALL manage categories\" \u2192 Need CRUD /categories APIs\n- \u274C \"THE system SHALL log all user actions\" \u2192 Internal logging, no API\n- \u274C \"THE system SHALL track performance metrics\" \u2192 Internal monitoring, no API\n\n**Decision Framework**:\n\nAsk these questions for each table:\n1. **Who creates this data?**\n   - User action \u2192 Need POST endpoint\n   - System automatically \u2192 NO POST endpoint\n\n2. **Who modifies this data?**\n   - User can edit \u2192 Need PUT/PATCH endpoint\n   - System only \u2192 NO PUT endpoint\n\n3. **Can this data be deleted?**\n   - User can delete \u2192 Need DELETE endpoint\n   - Must be preserved for audit/compliance \u2192 NO DELETE endpoint\n\n4. **Do users need to view this data?**\n   - Yes \u2192 Add GET/PATCH (search) endpoints\n   - No \u2192 No read endpoints needed\n\n**Common Examples (Your project may differ)**:\n- Audit-related tables: Usually system records actions automatically\n- Metrics/Analytics tables: Usually system collects data automatically\n- History/Log tables: Often system-generated, but check requirements\n- Important: These are examples only - always check your specific requirements\n\n**How to Identify System-Generated Tables**:\n- Look for requirements language: \"THE system SHALL automatically...\"\n- Consider the table's purpose: Is it for tracking/recording system behavior?\n- Ask: \"Would a user ever manually create/edit/delete this data?\"\n- Examples (may vary by project):\n  - Audit logs: System records actions automatically\n  - Analytics events: System tracks user behavior automatically\n  - Performance metrics: System collects measurements automatically\n\n**\u26A0\uFE0F MANDATORY**: DO NOT create operations for system-managed tables. These violate system integrity and create security vulnerabilities. Focus only on user-facing business operations.\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**CRITICAL: Selective Operation Generation**\n- You DO NOT need to create operations for every endpoint provided\n- **EXCLUDE** endpoints for system-generated data (logs, metrics, analytics)\n- **EXCLUDE** operations that violate the principles in Section 2.3\n- Return ONLY operations that represent legitimate user actions\n- The operations array can be smaller than the endpoints list - this is expected and correct\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      model_name: \"Resource\",\n      soft_delete_column: null\n    },\n    // ONLY include operations that pass validation\n    // DO NOT include system-generated data manipulation\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**\u26A0\uFE0F CRITICAL WARNING - Soft Delete Keywords**:\nDO NOT use terms like \"soft delete\", \"soft-delete\", or similar variations in the description or summary UNLESS the operation actually implements soft deletion. These keywords trigger validation logic that expects a corresponding `soft_delete_column` to be specified.\n\n**Why this matters**: The validation system checks for consistency between soft delete mentions and the `soft_delete_column` field. If you mention soft delete but don't implement it (or vice versa), validation will fail.\n\n**Examples of problematic descriptions**:\n- \u274C \"This would normally be a soft-delete, but we intentionally perform permanent deletion here\"\n- \u274C \"Unlike soft-delete operations, this permanently removes the record\"\n- \u274C \"This is not a soft delete - records are permanently removed\"\n\n**Instead, write**:\n- \u2705 \"This operation permanently removes the record from the database\"\n- \u2705 \"Records are completely deleted and cannot be recovered\"\n- \u2705 \"This performs a hard delete, removing all associated data\"\n\n**IMPORTANT**: All descriptions MUST be written in English. Never use other languages.\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#### 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: `\"index\"`\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  - **Important**: Only mention \"soft delete\" in summary/description if actually implementing soft deletion with a valid `soft_delete_column`\n\n### 5.4. Parameter Definition\n\nFor each path parameter in the endpoint path:\n- Extract parameter names from curly braces `{paramName}`\n- MUST use camelCase naming convention (start with lowercase, capitalize subsequent words)\n- Define appropriate schema type (usually string with UUID format)\n- Provide clear, concise description\n- Ensure parameter names match exactly with path\n\n**Naming Convention Rules**:\n- Valid: `userId`, `orderId`, `productId`, `categoryName`\n- Invalid: `user_id` (snake_case), `user-id` (kebab-case), `UserId` (PascalCase)\n\nExample:\n```typescript\n// For path: \"/users/{userId}/posts/{postId}\"\nparameters: [\n  {\n    name: \"userId\",  // camelCase required\n    description: \"Unique identifier of the target user\",\n    schema: { type: \"string\", format: \"uuid\" }\n  },\n  {\n    name: \"postId\",  // camelCase required\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. Operation Name Requirements\n\n#### Reserved Word Restrictions\n\n**CRITICAL**: The operation `name` field MUST NOT be a TypeScript/JavaScript reserved word, as it will be used as a class method name in generated code.\n\n**Prohibited Names** (DO NOT USE):\n- `delete`, `for`, `if`, `else`, `while`, `do`, `switch`, `case`, `break`\n- `continue`, `function`, `return`, `with`, `in`, `of`, `instanceof`\n- `typeof`, `void`, `var`, `let`, `const`, `class`, `extends`, `import`\n- `export`, `default`, `try`, `catch`, `finally`, `throw`, `new`\n- `super`, `this`, `null`, `true`, `false`, `async`, `await`\n- `yield`, `static`, `private`, `protected`, `public`, `implements`\n- `interface`, `package`, `enum`, `debugger`\n\n**Alternative Names to Use**:\n- Use `erase` instead of `delete`\n- Use `iterate` instead of `for`\n- Use `when` instead of `if`\n- Use `cls` instead of `class`\n- Use `retrieve` instead of `return`\n- Use `attempt` instead of `try`\n\n#### Operation Name Uniqueness Rule\n\nEach operation must have a globally unique accessor within the API. The accessor combines the path structure with the operation name.\n\n**Accessor Formation:**\n1. Extract non-parameter segments from the path (ignore `{...}` parts)\n2. Join these segments with dots\n3. Append the operation name to create the final accessor\n\n**Examples:**\n- Path: `/shopping/sale/{saleId}/review/{reviewId}`, Name: `at`\n  \u2192 Accessor: `shopping.sale.review.at`\n- Path: `/users/{userId}/posts`, Name: `index`\n  \u2192 Accessor: `users.posts.index`\n- Path: `/shopping/customer/orders`, Name: `create`\n  \u2192 Accessor: `shopping.customer.orders.create`\n\n**Global Uniqueness:**\nEvery accessor must be unique across the entire API. This prevents naming conflicts in generated SDKs where operations are accessed via dot notation (e.g., `api.shopping.sale.review.at()`)\n\n### 5.7. Model Name and Soft Delete Configuration\n\n#### Model Name Field\nThe `model_name` field identifies the primary Prisma model that this operation targets:\n- **Purpose**: Specifies which database table/model is the main subject of the operation\n- **Format**: Must exactly match the Prisma model name (case-sensitive)\n- **Examples**:\n  - For `/users/{userId}` \u2192 `model_name: \"User\"`\n  - For `/articles/{articleId}/comments` \u2192 `model_name: \"Comment\"`\n  - For `/shopping/orders` \u2192 `model_name: \"Order\"`\n\n**Important**: The model name must correspond to an actual model defined in your Prisma schema.\n\n#### Soft Delete Column Field\nThe `soft_delete_column` field specifies the column used for soft deletion:\n- **Purpose**: Identifies which field in the model is used to mark records as deleted without removing them from the database\n- **Format**: Exact field name from the Prisma model, or `null` if hard delete is used\n- **Common Patterns**:\n  - `\"deleted_at\"`: Timestamp field marking deletion time\n  - `\"deletedAt\"`: Camel-cased deletion timestamp\n  - `\"is_deleted\"`: Boolean flag for deletion status\n  - `null`: No soft deletion (hard delete will be performed)\n\n**Critical Rules**:\n1. **For DELETE operations**:\n   - If the model has a soft-delete field (like `deleted_at`), set `soft_delete_column` to that field name\n   - If the model uses hard deletion, set `soft_delete_column` to `null`\n   - The operation's summary/description should reflect whether it's soft or hard delete\n\n2. **Consistency Check**:\n   - If `soft_delete_column` is specified, the summary or description MUST mention \"soft delete\"\n   - If summary/description mentions \"soft delete\", the `soft_delete_column` MUST be specified\n   - The specified column must exist in the model's Prisma schema\n   - **WARNING**: Never use \"soft delete\" terminology unless actually implementing it\n   - Avoid phrases like \"unlike soft-delete\" or \"not a soft delete\" as these still trigger validation\n\n3. **For non-DELETE operations**:\n   - Generally set to `null` unless the operation specifically deals with soft-deleted records\n   - GET/PATCH operations that filter out soft-deleted records should document this behavior\n\n**Example**:\n```typescript\n// For a model with soft delete capability\n{\n  method: \"delete\",\n  path: \"/articles/{articleId}\",\n  model_name: \"Article\",\n  soft_delete_column: \"deleted_at\",\n  summary: \"Soft delete an article by marking it as deleted\",\n  // ... other fields\n}\n\n// For a model using hard delete\n{\n  method: \"delete\",\n  path: \"/temp-files/{fileId}\",\n  model_name: \"TempFile\",\n  soft_delete_column: null,\n  summary: \"Permanently remove a temporary file from the system\",\n  // ... other fields\n}\n```\n\n### 5.8. 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**CRITICAL Naming Convention**: All role names MUST use camelCase:\n- Valid: `user`, `admin`, `moderator`, `seller`, `buyer`, `contentCreator`\n- Invalid: `content_creator` (snake_case), `ContentCreator` (PascalCase), `content-creator` (kebab-case)\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**Important**: Role names must exactly match table names in the Prisma schema and must follow camelCase convention.\n\n## 6. Critical Requirements\n\n- **Function Call Required**: You MUST use the `makeOperations()` function to submit your results\n- **Selective Processing**: Evaluate EVERY endpoint but ONLY create operations for valid ones\n- **Intentional Exclusion**: MUST skip endpoints that:\n  - Manipulate system-generated data (POST/PUT/DELETE on logs, metrics, etc.)\n  - Violate architectural principles\n  - Serve no real user need\n- **Prisma Schema Alignment**: All operations must accurately reflect the underlying database schema\n- **Model Identification**: Every operation MUST specify the correct `model_name` matching the Prisma schema\n- **Soft Delete Configuration**: DELETE operations MUST correctly specify `soft_delete_column` based on the model's 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 and Filter Input**:\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   - **CRITICAL**: Evaluate each endpoint - exclude system-generated data manipulation\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 (Selective)**:\n   - For each VALID endpoint, determine the appropriate operation pattern\n   - **SKIP** endpoints that manipulate system-generated data\n   - **SKIP** endpoints that serve no real user need\n   - Create detailed specifications ONLY for legitimate user operations\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 filtered array (may be smaller than input endpoints)\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  prisma_schemas: `\n    model Customer {\n      id            String    @id @default(uuid())\n      email         String    @unique\n      name          String\n      phone         String?\n      address       String?\n      status        String    @default(\"active\") // active, inactive, suspended\n      created_at    DateTime  @default(now())\n      updated_at    DateTime  @updatedAt\n      deleted_at    DateTime? // Soft-delete field for logical deletion\n      \n      orders        Order[]\n      reviews       Review[]\n      cart_items    CartItem[]\n      \n      @@index([email])\n      @@index([created_at])\n      @@index([deleted_at])\n    }\n    \n    model Order {\n      id            String    @id @default(uuid())\n      customer_id   String\n      customer      Customer  @relation(fields: [customer_id], references: [id])\n      total_amount  Float\n      status        String    // pending, confirmed, shipped, delivered, cancelled\n      created_at    DateTime  @default(now())\n      \n      @@index([customer_id])\n    }\n  `,\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  model_name: \"Customer\",\n  soft_delete_column: \"deleted_at\"\n}\n```\n\nYour implementation MUST be SELECTIVE and THOUGHTFUL, excluding inappropriate endpoints (system-generated data manipulation) while ensuring every VALID operation provides comprehensive, production-ready API documentation. The result array should contain ONLY operations that represent real user actions. Calling the `makeOperations()` function is MANDATORY." /* AutoBeSystemPromptConstant.INTERFACE_OPERATION */,
         },
         ...(0, transformInterfaceAssetHistories_1.transformInterfaceAssetHistories)(state),
         {
             type: "systemMessage",
-            id: (0, uuid_1.v4)(),
+            id: (0, uuid_1.v7)(),
             created_at: new Date().toISOString(),
-            text: [
-                `## Service Prefix`,
-                `- Original: ${analyze.prefix}`,
-                `- PascalCase for DTOs: ${analyze.prefix
-                    .split(/[-_]/)
-                    .map((p) => p.charAt(0).toUpperCase() + p.slice(1))
-                    .join("")}`,
-                `- Expected DTO pattern: I${analyze.prefix
-                    .split(/[-_]/)
-                    .map((p) => p.charAt(0).toUpperCase() + p.slice(1))
-                    .join("")}{EntityName}`,
-            ].join("\n"),
+            text: utils_1.StringUtil.trim `
+        ## Service Prefix
+        - Original: ${analyze.prefix}
+        - PascalCase for DTOs: ${analyze.prefix
+                .split(/[-_]/)
+                .map((p) => p.charAt(0).toUpperCase() + p.slice(1))
+                .join("")}
+        - Expected DTO pattern: I${analyze.prefix
+                .split(/[-_]/)
+                .map((p) => p.charAt(0).toUpperCase() + p.slice(1))
+                .join("")}{EntityName}
+      `,
         },
         {
             type: "assistantMessage",
-            id: (0, uuid_1.v4)(),
+            id: (0, uuid_1.v7)(),
             created_at: new Date().toISOString(),
-            text: [
-                "You have to make API operations for the given endpoints:",
-                "",
-                "```json",
-                JSON.stringify(endpoints),
-                "```",
-                "",
-                "If there is a content in the failure, it is to explain why it failed before.",
-                "Please supplement or modify the Operation accordingly.",
-            ].join("\n"),
+            text: utils_1.StringUtil.trim `
+        You have to make API operations for the given endpoints:
+
+        \`\`\`json
+        ${JSON.stringify(endpoints)}
+        \`\`\`
+
+        If there is a content in the failure, it is to explain why it failed before.
+        Please supplement or modify the Operation accordingly.
+      `,
         },
     ];
 };

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

@@ -1 +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;IACF,MAAM,OAAO,GAAyB,KAAK,CAAC,OAAQ,CAAC;IACrD,OAAO;QACL;YACE,IAAI,EAAE,eAAe;YACrB,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,ijwBAAgD;SACrD;QACD,GAAG,IAAA,mEAAgC,EAAC,KAAK,CAAC;QAC1C;YACE,IAAI,EAAE,eAAe;YACrB,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE;gBACJ,mBAAmB;gBACnB,eAAe,OAAO,CAAC,MAAM,EAAE;gBAC/B,0BAA0B,OAAO,CAAC,MAAM;qBACrC,KAAK,CAAC,MAAM,CAAC;qBACb,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC;qBAClD,IAAI,CAAC,EAAE,CAAC,EAAE;gBACb,4BAA4B,OAAO,CAAC,MAAM;qBACvC,KAAK,CAAC,MAAM,CAAC;qBACb,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC;qBAClD,IAAI,CAAC,EAAE,CAAC,cAAc;aAC1B,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;QACD;YACE,IAAI,EAAE,kBAAkB;YACxB,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE;gBACJ,0DAA0D;gBAC1D,EAAE;gBACF,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,SAAS,CAAC;gBACzB,KAAK;gBACL,EAAE;gBACF,8EAA8E;gBAC9E,wDAAwD;aACzD,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AAhDW,QAAA,oCAAoC,wCAgD/C"}
+{"version":3,"file":"transformInterfaceOperationHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/interface/histories/transformInterfaceOperationHistories.ts"],"names":[],"mappings":";;;AAEA,yCAA2C;AAC3C,+BAA0B;AAI1B,yFAAsF;AAE/E,MAAM,oCAAoC,GAAG,CAClD,KAAkB,EAClB,SAAoC,EAGpC,EAAE;IACF,MAAM,OAAO,GAAyB,KAAK,CAAC,OAAQ,CAAC;IACrD,OAAO;QACL;YACE,IAAI,EAAE,eAAe;YACrB,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,m37BAAgD;SACrD;QACD,GAAG,IAAA,mEAAgC,EAAC,KAAK,CAAC;QAC1C;YACE,IAAI,EAAE,eAAe;YACrB,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;sBAEL,OAAO,CAAC,MAAM;iCACH,OAAO,CAAC,MAAM;iBACpC,KAAK,CAAC,MAAM,CAAC;iBACb,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC;iBAClD,IAAI,CAAC,EAAE,CAAC;mCACgB,OAAO,CAAC,MAAM;iBACtC,KAAK,CAAC,MAAM,CAAC;iBACb,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC;iBAClD,IAAI,CAAC,EAAE,CAAC;OACZ;SACF;QACD;YACE,IAAI,EAAE,kBAAkB;YACxB,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;UAIjB,IAAI,CAAC,SAAS,CAAC,SAAS,CAAC;;;;;OAK5B;SACF;KACF,CAAC;AACJ,CAAC,CAAC;AAhDW,QAAA,oCAAoC,wCAgD/C"}