@autobe/agent 0.30.0-dev.20260315 → 0.30.1

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

@@ -17,43 +17,43 @@ const transformInterfaceActionEndpointWriteHistory = (props) => ({
             type: "assistantMessage",
             id: (0, uuid_1.v7)(),
             created_at: new Date().toISOString(),
-            text: utils_1.StringUtil.trim `
-        ## API Design Instructions (Reference)
-
-        The following API-specific instructions were extracted from
-        the user's requirements. These focus on API interface design aspects
-        such as endpoint patterns, request/response formats, DTO schemas,
-        and operation specifications.
-
-        Carefully distinguish between:
-        - Suggestions or recommendations (consider these as guidance)
-        - Direct specifications or explicit commands (these must be followed exactly)
-
-        When instructions contain direct specifications or explicit design decisions,
-        follow them precisely even if you believe you have better alternatives.
-
-        ${props.instruction}
-
-        ## Base CRUD Endpoints (Reference - Already Exist)
-
-        These base CRUD endpoints already exist. Do NOT create similar endpoints.
-        Action endpoints should complement these, not duplicate them:
-
-        \`\`\`json
-        ${JSON.stringify(props.baseEndpoints)}
-        \`\`\`
-
-        ${(0, transformInterfaceEndpointAuthorizationSection_1.transformInterfaceEndpointAuthorizationSection)(props.authorizeOperations)}
-        
-        ## Target Group for Design (YOUR TASK)
-
-        You are designing action endpoints for the **${props.group.name}** group.
-
-        \`\`\`json
-        ${JSON.stringify(props.group)}
-        \`\`\`
-
-        Design action endpoints that fulfill the requirements for this group.
+            text: utils_1.StringUtil.trim `
+        ## API Design Instructions (Reference)
+
+        The following API-specific instructions were extracted from
+        the user's requirements. These focus on API interface design aspects
+        such as endpoint patterns, request/response formats, DTO schemas,
+        and operation specifications.
+
+        Carefully distinguish between:
+        - Suggestions or recommendations (consider these as guidance)
+        - Direct specifications or explicit commands (these must be followed exactly)
+
+        When instructions contain direct specifications or explicit design decisions,
+        follow them precisely even if you believe you have better alternatives.
+
+        ${props.instruction}
+
+        ## Base CRUD Endpoints (Reference - Already Exist)
+
+        These base CRUD endpoints already exist. Do NOT create similar endpoints.
+        Action endpoints should complement these, not duplicate them:
+
+        \`\`\`json
+        ${JSON.stringify(props.baseEndpoints)}
+        \`\`\`
+
+        ${(0, transformInterfaceEndpointAuthorizationSection_1.transformInterfaceEndpointAuthorizationSection)(props.authorizeOperations)}
+        
+        ## Target Group for Design (YOUR TASK)
+
+        You are designing action endpoints for the **${props.group.name}** group.
+
+        \`\`\`json
+        ${JSON.stringify(props.group)}
+        \`\`\`
+
+        Design action endpoints that fulfill the requirements for this group.
         `,
         },
     ],

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

@@ -11,16 +11,16 @@ const transformInterfaceAuthorizationHistory = (props) => {
         prefix: props.prefix,
         actor: props.actor.name,
     });
-    const table = utils_1.StringUtil.trim `
-    Authorization Type | Request Body Type | Response Body Type
-    -------------------|-------------------|--------------------
+    const table = utils_1.StringUtil.trim `
+    Authorization Type | Request Body Type | Response Body Type
+    -------------------|-------------------|--------------------
     ${["join", ...(props.actor.kind !== "guest" ? ["login"] : []), "refresh"]
         .map((type) => [
         type,
         `${typeName}.I${utils_2.NamingConvention.pascal(type)}`,
         `${typeName}.IAuthorized`,
     ].join(" | "))
-        .join("\n    ")}
+        .join("\n    ")}
   `;
     return {
         histories: [
@@ -35,72 +35,72 @@ const transformInterfaceAuthorizationHistory = (props) => {
                 type: "systemMessage",
                 id: (0, uuid_1.v7)(),
                 created_at: new Date().toISOString(),
-                text: utils_1.StringUtil.trim `
-          ## Service Prefix
-          - Original: ${analyze.prefix}
+                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("")}
+                    .join("")}
           - Expected DTO pattern: I${analyze.prefix
                     .split(/[-_]/)
                     .map((p) => p.charAt(0).toUpperCase() + p.slice(1))
-                    .join("")}{EntityName}
+                    .join("")}{EntityName}
         `,
             },
             {
                 type: "assistantMessage",
                 id: (0, uuid_1.v7)(),
                 created_at: new Date().toISOString(),
-                text: utils_1.StringUtil.trim `
-          ## API Design Instructions
-
-          The following API-specific instructions were extracted from
-          the user's requirements. These focus on API interface design aspects
-          such as endpoint patterns, request/response formats, DTO schemas,
-          and operation specifications.
-
-          Follow these instructions when designing authorization operations for ${props.actor.name}.
-          Carefully distinguish between:
-          - Suggestions or recommendations (consider these as guidance)
-          - Direct specifications or explicit commands (these must be followed exactly)
-
-          When instructions contain direct specifications or explicit design decisions,
-          follow them precisely even if you believe you have better alternatives.
-
-          ${props.instruction}
-
-          ## Actor
-
-          You have to make API operations for the given actor:
-
-          \`\`\`json
-          ${JSON.stringify(props.actor)}
-          \`\`\`
-
-          ## Authorization Operations Table
-
-          The table below specifies the required authorization operations and their **exact type names**.
-          These type names are pre-determined based on the service prefix and actor name - do NOT deviate from them.
-
-          Each column means:
-          - **Authorization Type**: The value for \`AutoBeOpenApi.IOperation.authorizationType\` (one of \`"join"\`, \`"login"\`, or \`"refresh"\`)
-          - **Request Body Type Name**: The exact DTO type name for \`requestBody.typeName\`
-          - **Response Body Type Name**: The exact DTO type name for \`responseBody.typeName\` (always \`IAuthorized\` containing tokens)
-
-          ${table}
-
+                text: utils_1.StringUtil.trim `
+          ## API Design Instructions
+
+          The following API-specific instructions were extracted from
+          the user's requirements. These focus on API interface design aspects
+          such as endpoint patterns, request/response formats, DTO schemas,
+          and operation specifications.
+
+          Follow these instructions when designing authorization operations for ${props.actor.name}.
+          Carefully distinguish between:
+          - Suggestions or recommendations (consider these as guidance)
+          - Direct specifications or explicit commands (these must be followed exactly)
+
+          When instructions contain direct specifications or explicit design decisions,
+          follow them precisely even if you believe you have better alternatives.
+
+          ${props.instruction}
+
+          ## Actor
+
+          You have to make API operations for the given actor:
+
+          \`\`\`json
+          ${JSON.stringify(props.actor)}
+          \`\`\`
+
+          ## Authorization Operations Table
+
+          The table below specifies the required authorization operations and their **exact type names**.
+          These type names are pre-determined based on the service prefix and actor name - do NOT deviate from them.
+
+          Each column means:
+          - **Authorization Type**: The value for \`AutoBeOpenApi.IOperation.authorizationType\` (one of \`"join"\`, \`"login"\`, or \`"refresh"\`)
+          - **Request Body Type Name**: The exact DTO type name for \`requestBody.typeName\`
+          - **Response Body Type Name**: The exact DTO type name for \`responseBody.typeName\` (always \`IAuthorized\` containing tokens)
+
+          ${table}
+
           ${props.actor.kind === "guest"
                     ? "> This actor is `guest` kind, so `login` operation is excluded. Guests authenticate via join/refresh only."
-                    : ""}
-
-          **⚠️ MANDATORY REQUIREMENT**: You MUST generate ALL operations listed in the table above.
-          Every single row represents a required operation - do NOT skip or omit any of them.
-          The validator will reject your output if any operation is missing.
-
-          When you create each operation's request/response body schemas,
-          you MUST use these exact type names. The validator will reject any
-          operation that does not match these specifications exactly.
+                    : ""}
+
+          **⚠️ MANDATORY REQUIREMENT**: You MUST generate ALL operations listed in the table above.
+          Every single row represents a required operation - do NOT skip or omit any of them.
+          The validator will reject your output if any operation is missing.
+
+          When you create each operation's request/response body schemas,
+          you MUST use these exact type names. The validator will reject any
+          operation that does not match these specifications exactly.
         `,
             },
         ],

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

@@ -22,32 +22,32 @@ const transformInterfaceBaseEndpointReviewHistory = (props) => ({
         {
             id: (0, uuid_1.v7)(),
             type: "assistantMessage",
-            text: utils_1.StringUtil.trim `
-        ## Target Group
-
-        You are reviewing endpoints for the **${props.group.name}** group.
-
-        - **Description**: ${props.group.description}
-        - **Related Database Schemas**: ${props.group.databaseSchemas.join(", ")}
-
-        ${(0, transformInterfaceEndpointAuthorizationSection_1.transformInterfaceEndpointAuthorizationSection)(props.authorizeOperations)}
-        
-        ## Base CRUD Endpoint Designs for Review (YOUR TASK)
-
-        ⚠️ CRITICAL: You MUST provide a revision for EVERY endpoint listed below.
-
-        - Use **keep** to approve endpoints that are correct
-        - Use **update** to fix endpoints with issues
-        - Use **erase** to remove invalid endpoints
-        - Use **create** to add missing endpoints
-
-        DO NOT omit any endpoint. DO NOT reference endpoints not listed here.
-
-        \`\`\`json
-        ${JSON.stringify(props.designs)}
-        \`\`\`
-
-        Review according to the criteria in the system prompt. Call \`process()\` with \`type: "complete"\` containing all \`revises\`.
+            text: utils_1.StringUtil.trim `
+        ## Target Group
+
+        You are reviewing endpoints for the **${props.group.name}** group.
+
+        - **Description**: ${props.group.description}
+        - **Related Database Schemas**: ${props.group.databaseSchemas.join(", ")}
+
+        ${(0, transformInterfaceEndpointAuthorizationSection_1.transformInterfaceEndpointAuthorizationSection)(props.authorizeOperations)}
+        
+        ## Base CRUD Endpoint Designs for Review (YOUR TASK)
+
+        ⚠️ CRITICAL: You MUST provide a revision for EVERY endpoint listed below.
+
+        - Use **keep** to approve endpoints that are correct
+        - Use **update** to fix endpoints with issues
+        - Use **erase** to remove invalid endpoints
+        - Use **create** to add missing endpoints
+
+        DO NOT omit any endpoint. DO NOT reference endpoints not listed here.
+
+        \`\`\`json
+        ${JSON.stringify(props.designs)}
+        \`\`\`
+
+        Review according to the criteria in the system prompt. Call \`process()\` with \`type: "complete"\` containing all \`revises\`.
       `,
             created_at: new Date().toISOString(),
         },

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

@@ -17,34 +17,34 @@ const transformInterfaceBaseEndpointWriteHistory = (props) => ({
             type: "assistantMessage",
             id: (0, uuid_1.v7)(),
             created_at: new Date().toISOString(),
-            text: utils_1.StringUtil.trim `
-        ## API Design Instructions (Reference)
-
-        The following API-specific instructions were extracted from
-        the user's requirements. These focus on API interface design aspects
-        such as endpoint patterns, request/response formats, DTO schemas,
-        and operation specifications.
-
-        Carefully distinguish between:
-        - Suggestions or recommendations (consider these as guidance)
-        - Direct specifications or explicit commands (these must be followed exactly)
-
-        When instructions contain direct specifications or explicit design decisions,
-        follow them precisely even if you believe you have better alternatives.
-
-        ${props.instruction}
-
-        ${(0, transformInterfaceEndpointAuthorizationSection_1.transformInterfaceEndpointAuthorizationSection)(props.authorizeOperations)}
-        
-        ## Target Group for Design (YOUR TASK)
-
-        You are designing base CRUD endpoints for the **${props.group.name}** group.
-
-        \`\`\`json
-        ${JSON.stringify(props.group)}
-        \`\`\`
-
-        Design base CRUD endpoints that cover all entities in this group.
+            text: utils_1.StringUtil.trim `
+        ## API Design Instructions (Reference)
+
+        The following API-specific instructions were extracted from
+        the user's requirements. These focus on API interface design aspects
+        such as endpoint patterns, request/response formats, DTO schemas,
+        and operation specifications.
+
+        Carefully distinguish between:
+        - Suggestions or recommendations (consider these as guidance)
+        - Direct specifications or explicit commands (these must be followed exactly)
+
+        When instructions contain direct specifications or explicit design decisions,
+        follow them precisely even if you believe you have better alternatives.
+
+        ${props.instruction}
+
+        ${(0, transformInterfaceEndpointAuthorizationSection_1.transformInterfaceEndpointAuthorizationSection)(props.authorizeOperations)}
+        
+        ## Target Group for Design (YOUR TASK)
+
+        You are designing base CRUD endpoints for the **${props.group.name}** group.
+
+        \`\`\`json
+        ${JSON.stringify(props.group)}
+        \`\`\`
+
+        Design base CRUD endpoints that cover all entities in this group.
         `,
         },
     ],

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

@@ -23,17 +23,17 @@ const transformInterfaceEndpointAuthorizationSection = (operations) => {
             ].join(" | ");
         }),
     ].join("\n");
-    return utils_1.StringUtil.trim `
-    ## Already Generated Authorization Operations (DO NOT DUPLICATE)
-
-    The following authorization operations have already been generated 
-    by the Authorization Agent.
-    
-    Do NOT create any endpoints that duplicate these operations. All 
-    authentication-related operations are handled exclusively by 
-    the Authorization Agent. This is not your responsibility.
-
-    ${table}
+    return utils_1.StringUtil.trim `
+    ## Already Generated Authorization Operations (DO NOT DUPLICATE)
+
+    The following authorization operations have already been generated 
+    by the Authorization Agent.
+    
+    Do NOT create any endpoints that duplicate these operations. All 
+    authentication-related operations are handled exclusively by 
+    the Authorization Agent. This is not your responsibility.
+
+    ${table}
   `;
 };
 exports.transformInterfaceEndpointAuthorizationSection = transformInterfaceEndpointAuthorizationSection;

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

@@ -26,55 +26,55 @@ const transformInterfaceGroupHistory = (props) => {
                 id: (0, uuid_1.v7)(),
                 created_at: new Date().toISOString(),
                 type: "assistantMessage",
-                text: utils_1.StringUtil.trim `
-          Here is the database grouping information you can reference.
-
-          However, database groups are your **STARTING POINT**, not your **STRICT BOUNDARY**:
-
-          - **Use database groups as your BASELINE**: Most API groups should align with database 
-                                                      groups (1:1 mapping)
-          - **API ≠ Database**: APIs serve different purposes than normalized database schemas
-            • APIs organize by **USER WORKFLOWS** (how users interact)
-            • Databases organize by **DATA NORMALIZATION** (how data is stored)
-          - **When to DIVERGE from database groups**:
-            • Cross-schema operations: Analytics/dashboards aggregating multiple database groups
-            • Workflow-based APIs: Checkout spanning Carts + Orders + Payments
-            • Pure computation: APIs that don't touch database at all
-            • External integrations: Webhooks, third-party API gateways
-          - **CRITICAL**: Don't create 1-2 mega-groups ignoring database organization. 
-                          Start with database groups, then add API-specific groups as needed.
-
-          Belonged Namespace | Table Name | Stance | Summary
-          -------------------|------------|--------|-----------
+                text: utils_1.StringUtil.trim `
+          Here is the database grouping information you can reference.
+
+          However, database groups are your **STARTING POINT**, not your **STRICT BOUNDARY**:
+
+          - **Use database groups as your BASELINE**: Most API groups should align with database 
+                                                      groups (1:1 mapping)
+          - **API ≠ Database**: APIs serve different purposes than normalized database schemas
+            • APIs organize by **USER WORKFLOWS** (how users interact)
+            • Databases organize by **DATA NORMALIZATION** (how data is stored)
+          - **When to DIVERGE from database groups**:
+            • Cross-schema operations: Analytics/dashboards aggregating multiple database groups
+            • Workflow-based APIs: Checkout spanning Carts + Orders + Payments
+            • Pure computation: APIs that don't touch database at all
+            • External integrations: Webhooks, third-party API gateways
+          - **CRITICAL**: Don't create 1-2 mega-groups ignoring database organization. 
+                          Start with database groups, then add API-specific groups as needed.
+
+          Belonged Namespace | Table Name | Stance | Summary
+          -------------------|------------|--------|-----------
           ${app === null || app === void 0 ? void 0 : app.files.map((file) => file.models.map((model) => [file, model])).flat().map(([file, model]) => [
                     file.namespace,
                     model.name,
                     model.stance,
                     utils_1.StringUtil.summary(model.description),
-                ].join(" | ")).join("\n")}
+                ].join(" | ")).join("\n")}
         `,
             },
             {
                 id: (0, uuid_1.v7)(),
                 created_at: new Date().toISOString(),
                 type: "assistantMessage",
-                text: utils_1.StringUtil.trim `
-          ## API Design Instructions
-
-          The following API-specific instructions were extracted from
-          the user's requirements. These focus on API interface design aspects
-          such as endpoint patterns, request/response formats, DTO schemas,
-          and operation specifications.
-
-          Follow these instructions when organizing API endpoints.
-          Carefully distinguish between:
-          - Suggestions or recommendations (consider these as guidance)
-          - Direct specifications or explicit commands (these must be followed exactly)
-
-          When instructions contain direct specifications or explicit design decisions,
-          follow them precisely even if you believe you have better alternatives.
-
-          ${props.instruction}
+                text: utils_1.StringUtil.trim `
+          ## API Design Instructions
+
+          The following API-specific instructions were extracted from
+          the user's requirements. These focus on API interface design aspects
+          such as endpoint patterns, request/response formats, DTO schemas,
+          and operation specifications.
+
+          Follow these instructions when organizing API endpoints.
+          Carefully distinguish between:
+          - Suggestions or recommendations (consider these as guidance)
+          - Direct specifications or explicit commands (these must be followed exactly)
+
+          When instructions contain direct specifications or explicit design decisions,
+          follow them precisely even if you believe you have better alternatives.
+
+          ${props.instruction}
         `,
             },
         ],

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

@@ -17,47 +17,47 @@ const transformInterfaceOperationHistory = (props) => {
                 type: "systemMessage",
                 id: (0, uuid_1.v7)(),
                 created_at: new Date().toISOString(),
-                text: utils_1.StringUtil.trim `
-          ## Service Prefix
-          - Original: ${props.prefix}
+                text: utils_1.StringUtil.trim `
+          ## Service Prefix
+          - Original: ${props.prefix}
           - PascalCase for DTOs: ${props.prefix
                     .split(/[-_]/)
                     .map((p) => p.charAt(0).toUpperCase() + p.slice(1))
-                    .join("")}
+                    .join("")}
           - Expected DTO pattern: I${props.prefix
                     .split(/[-_]/)
                     .map((p) => p.charAt(0).toUpperCase() + p.slice(1))
-                    .join("")}{EntityName}
+                    .join("")}{EntityName}
         `,
             },
             {
                 type: "assistantMessage",
                 id: (0, uuid_1.v7)(),
                 created_at: new Date().toISOString(),
-                text: utils_1.StringUtil.trim `
-          ## API Design Instructions
-
-          The following API-specific instructions were extracted from
-          the user's requirements. These focus on API interface design aspects
-          such as endpoint patterns, request/response formats, DTO schemas,
-          and operation specifications.
-
-          Follow these instructions when designing operation specifications.
-          Carefully distinguish between:
-          - Suggestions or recommendations (consider these as guidance)
-          - Direct specifications or explicit commands (these must be followed exactly)
-
-          When instructions contain direct specifications or explicit design decisions,
-          follow them precisely even if you believe you have better alternatives.
-
-          ${props.instruction}
-
-          ## Operation
-
-          You have to make an API operation for the given endpoint:
-
-          - path: ${props.endpoint.path}
-          - method: ${props.endpoint.method}
+                text: utils_1.StringUtil.trim `
+          ## API Design Instructions
+
+          The following API-specific instructions were extracted from
+          the user's requirements. These focus on API interface design aspects
+          such as endpoint patterns, request/response formats, DTO schemas,
+          and operation specifications.
+
+          Follow these instructions when designing operation specifications.
+          Carefully distinguish between:
+          - Suggestions or recommendations (consider these as guidance)
+          - Direct specifications or explicit commands (these must be followed exactly)
+
+          When instructions contain direct specifications or explicit design decisions,
+          follow them precisely even if you believe you have better alternatives.
+
+          ${props.instruction}
+
+          ## Operation
+
+          You have to make an API operation for the given endpoint:
+
+          - path: ${props.endpoint.path}
+          - method: ${props.endpoint.method}
         `,
             },
         ],

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

@@ -15,33 +15,33 @@ exports.transformInterfaceOperationParameterHistory = transformInterfaceOperatio
 function writeActor(actors) {
     if (actors.length === 0)
         return null;
-    return utils_1.StringUtil.trim `
-    ### Authorization Actors
-
-    These following actors and their sessions are coming from 
-    the JWT authorization token, so you don't need to define them 
-    in the request body schema.
-
-    ${actors.map((a) => `- ${a}`).join("\n")}
+    return utils_1.StringUtil.trim `
+    ### Authorization Actors
+
+    These following actors and their sessions are coming from 
+    the JWT authorization token, so you don't need to define them 
+    in the request body schema.
+
+    ${actors.map((a) => `- ${a}`).join("\n")}
   `;
 }
 function writeOperations(operations) {
     operations = operations.filter((op) => op.parameters.length !== 0);
     if (operations.length === 0)
         return null;
-    return utils_1.StringUtil.trim `
-    ### Path Parameters
-
-    These following path parameters are defined for the operations,
-    so you don't need to define them in the request body schema.
-
+    return utils_1.StringUtil.trim `
+    ### Path Parameters
+
+    These following path parameters are defined for the operations,
+    so you don't need to define them in the request body schema.
+
     ${operations
         .map((op) => [
         `- ${op.method.toUpperCase()} ${op.path}`,
         ...op.parameters.map((p) => `  - \`${p.name}\``),
     ])
         .flat()
-        .join("\n")}
+        .join("\n")}
   `;
 }
 //# sourceMappingURL=transformInterfaceOperationParameterHistory.js.map

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

@@ -23,12 +23,12 @@ function transformInterfaceOperationReviewHistory(props) {
                 type: "assistantMessage",
                 id: (0, uuid_1.v7)(),
                 created_at: new Date().toISOString(),
-                text: utils_1.StringUtil.trim `
-          Review the following API operation:
-
-          \`\`\`json
-          ${JSON.stringify(props.operation)}
-          \`\`\`
+                text: utils_1.StringUtil.trim `
+          Review the following API operation:
+
+          \`\`\`json
+          ${JSON.stringify(props.operation)}
+          \`\`\`
         `,
             },
         ],