@autobe/agent 0.8.0 → 0.9.0

package/lib/orchestrate/test/transformTestScenarioHistories.js

@@ -2,7 +2,7 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.transformTestScenarioHistories = void 0;
 const uuid_1 = require("uuid");
-const transformTestScenarioHistories = (state, allEndpoints, files) => {
+const transformTestScenarioHistories = (state) => {
     if (state.analyze === null)
         return [
             {
@@ -77,47 +77,6 @@ const transformTestScenarioHistories = (state, allEndpoints, files) => {
             type: "systemMessage",
             text: "# System Prompt: User Scenario Generator for API Endpoints\n\n## Role Definition\nYou are a world-class User Experience Analyst and Business Scenario Expert who specializes in analyzing API endpoints to generate comprehensive user scenarios from a pure user perspective. Your scenarios will be used as documentation and comments in test code to help developers understand the real-world user context behind each test.\n\n## Primary Objective\nGenerate all possible scenarios that real users might experience with a single given API endpoint, focusing exclusively on user intentions, motivations, and behaviors rather than technical testing perspectives.\n\n## Core Constraints\n\n### Single Endpoint Limitation\n- Each scenario must be completely achievable using ONLY the provided endpoint\n- Do NOT create scenarios that require multiple API calls or dependencies on other endpoints\n- Each user journey must be self-contained and complete within this single endpoint interaction\n\n### Practicality Constraint for Scenario Quantity\n\n- Do NOT generate an excessive number of test scenarios for trivial endpoints.\n- If the endpoint is a simple read-only operation that returns a static or predictable object (e.g. `{ cpu: number, system: number }`), limit scenarios to those that reflect meaningful variations in user context, not in raw input permutations.\n- Avoid producing multiple user error or edge case scenarios when they provide no additional business insight.\n- Prioritize business relevance over theoretical input diversity.\n- The goal is to maximize scenario value, not quantity.\n\n\n## Scenario Generation Principles\n\n### 1. Pure User-Centric Perspective\n- Focus entirely on what users want to achieve through the API\n- Consider real business contexts and user motivations\n- Emphasize user intent and expected value over technical implementation\n- Write as if documenting actual user stories for product requirements\n\n### 2. Comprehensive Single-Endpoint Coverage\nConsider all the following perspectives when generating scenarios for the single endpoint:\n\n#### A. Happy Path User Journeys\n- Most common and expected user behaviors\n- Standard workflows that lead to successful user outcomes\n- Primary business use cases users perform with this endpoint\n\n#### B. Alternative User Approaches\n- Valid but different ways users might achieve their goals\n- Scenarios using optional parameters or different input combinations\n- Less common but legitimate user behaviors within normal boundaries\n\n#### C. User Error Situations\n- Natural user mistakes with input data (incorrect formats, missing fields)\n- User attempts without proper authentication or authorization\n- User actions that violate business rules or constraints\n- User encounters with system limitations\n\n#### D. Boundary User Behaviors\n- User attempts with extreme values (minimum/maximum limits)\n- User submissions with empty, null, or unusual data\n- User inputs with special characters, long strings, or edge cases\n- User interactions testing system boundaries\n\n#### E. Contextual User Situations\n- User interactions when resources exist vs. don't exist\n- Different user roles attempting the same actions\n- Time-sensitive user scenarios (expired sessions, scheduled operations)\n- User attempts during various system states\n\n### 3. Scenario Writing Format for Test Documentation\nWrite each scenario using the following structure optimized for test code comments:\n\n```\n**Scenario**: [Clear, descriptive title from user perspective]\n\n**User Context**: [Who is the user and why are they performing this action]\n\n**User Goal**: [What the user wants to accomplish]\n\n**User Actions**: [Specific steps the user takes with this endpoint]\n\n**Expected Experience**: [What the user expects to happen and how they'll know it worked]\n\n**Business Value**: [Why this scenario matters to the business]\n\n**Input Test Files**: [The test file names required for combining this scenario. If you have multiple files, connect them with commas.]\n```\n\n## Scenario Generation Checklist for Single Endpoint\n\n### Data Input Perspective\n- [ ] User providing complete, valid data\n- [ ] User missing required fields (intentionally or accidentally)\n- [ ] User sending incorrectly formatted data\n- [ ] User using boundary values (maximum/minimum)\n- [ ] User including special characters or multilingual content\n\n### User Permission Perspective\n- [ ] Users with appropriate permissions\n- [ ] Users with insufficient permissions\n- [ ] Unauthenticated users attempting access\n- [ ] Users with expired authentication\n\n### Resource State Perspective\n- [ ] User interacting when target resource exists\n- [ ] User interacting when target resource doesn't exist\n- [ ] User interacting with resources in various states\n- [ ] User encountering resources modified by others\n\n### User Experience Perspective\n- [ ] Users with realistic data volumes\n- [ ] Users performing time-sensitive operations\n- [ ] Users with different technical skill levels\n- [ ] Users in different business contexts\n\n### Business Context Perspective\n- [ ] Users following standard business processes\n- [ ] Users encountering business rule violations\n- [ ] Users in exceptional business situations\n- [ ] Users with varying business needs\n\n## Output Requirements for Test Documentation\n\nEach scenario must provide sufficient detail for developers to understand:\n\n1. **User Story Context**: Clear understanding of who the user is and their motivation\n2. **Business Justification**: Why this scenario matters for the product\n3. **User Behavior Pattern**: How real users would naturally interact with the endpoint\n4. **Success Criteria**: How users measure successful completion of their goal\n5. **Function Name Guidance**: Clear enough description to derive meaningful test function names\n\n## Quality Standards for Test Code Comments\n\n- Write scenarios that help developers empathize with real users\n- Focus on business value and user outcomes, not technical mechanics\n- Provide enough context that a developer can understand the user's situation\n- Ensure scenarios reflect realistic business situations\n- Make each scenario distinct and valuable for understanding user needs\n- Use language that both technical and non-technical stakeholders can understand\n\n## Guidelines\n\n- Avoid mentioning test code, assertions, or technical implementation details\n- Write purely from the user's perspective using narrative language\n- Create realistic scenarios that reflect actual business situations\n- Ensure scenarios are comprehensive yet practical for a single endpoint\n- Focus on user value and business outcomes\n- Make scenarios detailed enough to understand full user context\n\n## Expected Input\nYou will receive a single API endpoint specification including:\n- HTTP method and endpoint path\n- Request/response schemas\n- Authentication requirements\n- Parameter definitions\n- Business context when available\n\n## Expected Output\nFor the given API endpoint, provide:\n- Categorized user scenarios covering all perspectives mentioned above\n- Each scenario following the specified format for test documentation\n- Scenarios that are complete and achievable with only the single provided endpoint\n- Clear mapping between user intentions and the specific API operation\n- Sufficient detail to understand both user context and business value\n\n## Working Language\n- Default working language: English\n- Use the language specified by user in messages as the working language when explicitly provided\n- All thinking and responses must be in the working language\n- Maintain consistent perspective and tone throughout all scenarios" /* AutoBeSystemPromptConstant.TEST */,
         },
-        {
-            id: (0, uuid_1.v4)(),
-            created_at: new Date().toISOString(),
-            type: "systemMessage",
-            text: [
-                "# Result of Analyze Agent",
-                "- The following document contains the user requirements that were extracted through conversations with the user by the Analyze Agent.",
-                "- The database schema was designed based on these requirements, so you may refer to this document when writing test code or reviewing the schema.",
-                "",
-                `## User Request`,
-                "",
-                `- ${state.analyze.reason}`,
-                "",
-                `## Requirement Analysis Report`,
-                "",
-                "```json",
-                JSON.stringify(state.analyze.files),
-                "```",
-            ].join("\n"),
-        },
-        {
-            id: (0, uuid_1.v4)(),
-            created_at: new Date().toISOString(),
-            type: "systemMessage",
-            text: [
-                "# Result of Prisma Agent",
-                "- Given the following database schema and entity-relationship diagram, write appropriate test code to validate the constraints and relationships defined in the schema. For example, if there is a unique column, include a test that ensures its uniqueness.",
-                "- The test code should strictly adhere to the schema and relationships—no violations of constraints should occur.",
-                "- Use the information from the schema and diagram to design meaningful and accurate test cases.",
-                "",
-                "## Prisma DB Schema",
-                "```json",
-                JSON.stringify(state.prisma.schemas),
-                "```",
-                "",
-                "## Entity Relationship Diagrams",
-                "```json",
-                JSON.stringify(state.prisma.compiled.diagrams),
-                "```",
-            ].join("\n"),
-        },
         {
             id: (0, uuid_1.v4)(),
             created_at: new Date().toISOString(),
@@ -135,41 +94,6 @@ const transformTestScenarioHistories = (state, allEndpoints, files) => {
                 "```",
             ].join("\n"),
         },
-        {
-            id: (0, uuid_1.v4)(),
-            created_at: new Date().toISOString(),
-            type: "systemMessage",
-            text: "# System Prompt: User Scenario Generator for API Endpoints\n\n## Role Definition\nYou are a world-class User Experience Analyst and Business Scenario Expert who specializes in analyzing API endpoints to generate comprehensive user scenarios from a pure user perspective. Your scenarios will be used as documentation and comments in test code to help developers understand the real-world user context behind each test.\n\n## Primary Objective\nGenerate all possible scenarios that real users might experience with a single given API endpoint, focusing exclusively on user intentions, motivations, and behaviors rather than technical testing perspectives.\n\n## Core Constraints\n\n### Single Endpoint Limitation\n- Each scenario must be completely achievable using ONLY the provided endpoint\n- Do NOT create scenarios that require multiple API calls or dependencies on other endpoints\n- Each user journey must be self-contained and complete within this single endpoint interaction\n\n### Practicality Constraint for Scenario Quantity\n\n- Do NOT generate an excessive number of test scenarios for trivial endpoints.\n- If the endpoint is a simple read-only operation that returns a static or predictable object (e.g. `{ cpu: number, system: number }`), limit scenarios to those that reflect meaningful variations in user context, not in raw input permutations.\n- Avoid producing multiple user error or edge case scenarios when they provide no additional business insight.\n- Prioritize business relevance over theoretical input diversity.\n- The goal is to maximize scenario value, not quantity.\n\n\n## Scenario Generation Principles\n\n### 1. Pure User-Centric Perspective\n- Focus entirely on what users want to achieve through the API\n- Consider real business contexts and user motivations\n- Emphasize user intent and expected value over technical implementation\n- Write as if documenting actual user stories for product requirements\n\n### 2. Comprehensive Single-Endpoint Coverage\nConsider all the following perspectives when generating scenarios for the single endpoint:\n\n#### A. Happy Path User Journeys\n- Most common and expected user behaviors\n- Standard workflows that lead to successful user outcomes\n- Primary business use cases users perform with this endpoint\n\n#### B. Alternative User Approaches\n- Valid but different ways users might achieve their goals\n- Scenarios using optional parameters or different input combinations\n- Less common but legitimate user behaviors within normal boundaries\n\n#### C. User Error Situations\n- Natural user mistakes with input data (incorrect formats, missing fields)\n- User attempts without proper authentication or authorization\n- User actions that violate business rules or constraints\n- User encounters with system limitations\n\n#### D. Boundary User Behaviors\n- User attempts with extreme values (minimum/maximum limits)\n- User submissions with empty, null, or unusual data\n- User inputs with special characters, long strings, or edge cases\n- User interactions testing system boundaries\n\n#### E. Contextual User Situations\n- User interactions when resources exist vs. don't exist\n- Different user roles attempting the same actions\n- Time-sensitive user scenarios (expired sessions, scheduled operations)\n- User attempts during various system states\n\n### 3. Scenario Writing Format for Test Documentation\nWrite each scenario using the following structure optimized for test code comments:\n\n```\n**Scenario**: [Clear, descriptive title from user perspective]\n\n**User Context**: [Who is the user and why are they performing this action]\n\n**User Goal**: [What the user wants to accomplish]\n\n**User Actions**: [Specific steps the user takes with this endpoint]\n\n**Expected Experience**: [What the user expects to happen and how they'll know it worked]\n\n**Business Value**: [Why this scenario matters to the business]\n\n**Input Test Files**: [The test file names required for combining this scenario. If you have multiple files, connect them with commas.]\n```\n\n## Scenario Generation Checklist for Single Endpoint\n\n### Data Input Perspective\n- [ ] User providing complete, valid data\n- [ ] User missing required fields (intentionally or accidentally)\n- [ ] User sending incorrectly formatted data\n- [ ] User using boundary values (maximum/minimum)\n- [ ] User including special characters or multilingual content\n\n### User Permission Perspective\n- [ ] Users with appropriate permissions\n- [ ] Users with insufficient permissions\n- [ ] Unauthenticated users attempting access\n- [ ] Users with expired authentication\n\n### Resource State Perspective\n- [ ] User interacting when target resource exists\n- [ ] User interacting when target resource doesn't exist\n- [ ] User interacting with resources in various states\n- [ ] User encountering resources modified by others\n\n### User Experience Perspective\n- [ ] Users with realistic data volumes\n- [ ] Users performing time-sensitive operations\n- [ ] Users with different technical skill levels\n- [ ] Users in different business contexts\n\n### Business Context Perspective\n- [ ] Users following standard business processes\n- [ ] Users encountering business rule violations\n- [ ] Users in exceptional business situations\n- [ ] Users with varying business needs\n\n## Output Requirements for Test Documentation\n\nEach scenario must provide sufficient detail for developers to understand:\n\n1. **User Story Context**: Clear understanding of who the user is and their motivation\n2. **Business Justification**: Why this scenario matters for the product\n3. **User Behavior Pattern**: How real users would naturally interact with the endpoint\n4. **Success Criteria**: How users measure successful completion of their goal\n5. **Function Name Guidance**: Clear enough description to derive meaningful test function names\n\n## Quality Standards for Test Code Comments\n\n- Write scenarios that help developers empathize with real users\n- Focus on business value and user outcomes, not technical mechanics\n- Provide enough context that a developer can understand the user's situation\n- Ensure scenarios reflect realistic business situations\n- Make each scenario distinct and valuable for understanding user needs\n- Use language that both technical and non-technical stakeholders can understand\n\n## Guidelines\n\n- Avoid mentioning test code, assertions, or technical implementation details\n- Write purely from the user's perspective using narrative language\n- Create realistic scenarios that reflect actual business situations\n- Ensure scenarios are comprehensive yet practical for a single endpoint\n- Focus on user value and business outcomes\n- Make scenarios detailed enough to understand full user context\n\n## Expected Input\nYou will receive a single API endpoint specification including:\n- HTTP method and endpoint path\n- Request/response schemas\n- Authentication requirements\n- Parameter definitions\n- Business context when available\n\n## Expected Output\nFor the given API endpoint, provide:\n- Categorized user scenarios covering all perspectives mentioned above\n- Each scenario following the specified format for test documentation\n- Scenarios that are complete and achievable with only the single provided endpoint\n- Clear mapping between user intentions and the specific API operation\n- Sufficient detail to understand both user context and business value\n\n## Working Language\n- Default working language: English\n- Use the language specified by user in messages as the working language when explicitly provided\n- All thinking and responses must be in the working language\n- Maintain consistent perspective and tone throughout all scenarios" /* AutoBeSystemPromptConstant.TEST */,
-        },
-        {
-            id: (0, uuid_1.v4)(),
-            created_at: new Date().toISOString(),
-            type: "systemMessage",
-            text: [
-                `This is a description of different APIs.`,
-                `Different APIs may have to be called to create one.`,
-                `Check which functions have been developed.`,
-                "```json",
-                JSON.stringify(allEndpoints, null, 2),
-                "```",
-            ].join("\n"),
-        },
-        {
-            id: (0, uuid_1.v4)(),
-            created_at: new Date().toISOString(),
-            type: "systemMessage",
-            text: [
-                "Below is basically the generated test code,",
-                "which is a test to verify that the API is simply called and successful.",
-                "Since there is already an automatically generated API,",
-                "when a user requests to create a test scenario, two or more APIs must be combined,",
-                "but a test in which the currently given endpoint is the main must be created.",
-                '"Input Test Files" should be selected from the list of files here.',
-                "```json",
-                JSON.stringify(files, null, 2),
-                "```",
-            ].join("\n"),
-        },
     ];
 };
 exports.transformTestScenarioHistories = transformTestScenarioHistories;

package/lib/orchestrate/test/transformTestScenarioHistories.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformTestScenarioHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/test/transformTestScenarioHistories.ts"],"names":[],"mappings":";;;AAEA,+BAA0B;AAKnB,MAAM,8BAA8B,GAAG,CAC5C,KAAkB,EAClB,YAAuC,EACvC,KAA6B,EAG7B,EAAE;IACF,IAAI,KAAK,CAAC,OAAO,KAAK,IAAI;QACxB,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,4CAA4C;oBAC5C,mCAAmC;oBACnC,8CAA8C;iBAC/C,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,MAAM,KAAK,IAAI;QAC5B,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,mDAAmD;oBACnD,mCAAmC;oBACnC,qDAAqD;iBACtD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,OAAO,CAAC,IAAI,KAAK,KAAK,CAAC,MAAM,CAAC,IAAI;QAC/C,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,kDAAkD;oBAClD,sCAAsC;oBACtC,mCAAmC;oBACnC,wDAAwD;iBACzD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,MAAM,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;QAC/C,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,kDAAkD;oBAClD,sCAAsC;oBACtC,mCAAmC;oBACnC,wDAAwD;iBACzD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,SAAS,KAAK,IAAI;QAC/B,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,4CAA4C;oBAC5C,mCAAmC;oBACnC,8CAA8C;iBAC/C,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;IAEJ,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,6mPAAiC;SACtC;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE;gBACJ,2BAA2B;gBAC3B,uIAAuI;gBACvI,mJAAmJ;gBACnJ,EAAE;gBACF,iBAAiB;gBACjB,EAAE;gBACF,KAAK,KAAK,CAAC,OAAO,CAAC,MAAM,EAAE;gBAC3B,EAAE;gBACF,gCAAgC;gBAChC,EAAE;gBACF,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC;gBACnC,KAAK;aACN,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE;gBACJ,0BAA0B;gBAC1B,+PAA+P;gBAC/P,mHAAmH;gBACnH,iGAAiG;gBACjG,EAAE;gBACF,qBAAqB;gBACrB,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,MAAM,CAAC,OAAO,CAAC;gBACpC,KAAK;gBACL,EAAE;gBACF,iCAAiC;gBACjC,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,MAAM,CAAC,QAAQ,CAAC,QAAQ,CAAC;gBAC9C,KAAK;aACN,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE;gBACJ,8BAA8B;gBAC9B,yCAAyC;gBACzC,EAAE;gBACF,gEAAgE;gBAChE,qCAAqC;gBACrC,EAAE;gBACF,qBAAqB;gBACrB,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,SAAS,CAAC,QAAQ,CAAC;gBACxC,KAAK;aACN,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,6mPAAiC;SACtC;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE;gBACJ,0CAA0C;gBAC1C,qDAAqD;gBACrD,4CAA4C;gBAC5C,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,YAAY,EAAE,IAAI,EAAE,CAAC,CAAC;gBACrC,KAAK;aACN,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE;gBACJ,6CAA6C;gBAC7C,yEAAyE;gBACzE,wDAAwD;gBACxD,oFAAoF;gBACpF,+EAA+E;gBAC/E,oEAAoE;gBACpE,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,EAAE,IAAI,EAAE,CAAC,CAAC;gBAC9B,KAAK;aACN,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AAhLW,QAAA,8BAA8B,kCAgLzC"}
+{"version":3,"file":"transformTestScenarioHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/test/transformTestScenarioHistories.ts"],"names":[],"mappings":";;;AACA,+BAA0B;AAKnB,MAAM,8BAA8B,GAAG,CAC5C,KAAkB,EAGlB,EAAE;IACF,IAAI,KAAK,CAAC,OAAO,KAAK,IAAI;QACxB,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,4CAA4C;oBAC5C,mCAAmC;oBACnC,8CAA8C;iBAC/C,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,MAAM,KAAK,IAAI;QAC5B,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,mDAAmD;oBACnD,mCAAmC;oBACnC,qDAAqD;iBACtD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,OAAO,CAAC,IAAI,KAAK,KAAK,CAAC,MAAM,CAAC,IAAI;QAC/C,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,kDAAkD;oBAClD,sCAAsC;oBACtC,mCAAmC;oBACnC,wDAAwD;iBACzD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,MAAM,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;QAC/C,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,kDAAkD;oBAClD,sCAAsC;oBACtC,mCAAmC;oBACnC,wDAAwD;iBACzD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,SAAS,KAAK,IAAI;QAC/B,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,4CAA4C;oBAC5C,mCAAmC;oBACnC,8CAA8C;iBAC/C,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;IAEJ,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,6mPAAiC;SACtC;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE;gBACJ,8BAA8B;gBAC9B,yCAAyC;gBACzC,EAAE;gBACF,gEAAgE;gBAChE,qCAAqC;gBACrC,EAAE;gBACF,qBAAqB;gBACrB,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,SAAS,CAAC,QAAQ,CAAC;gBACxC,KAAK;aACN,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AAlGW,QAAA,8BAA8B,kCAkGzC"}

package/lib/structures/IAutoBeConfig.d.ts

@@ -1,24 +1,62 @@
+/**
+ * Interface defining behavioral configuration for AutoBeAgent localization and
+ * context.
+ *
+ * This interface customizes the agent's communication style, language
+ * preferences, and geographical context to provide personalized vibe coding
+ * experiences. The configuration enables culturally appropriate interactions
+ * and regionally aware development decisions throughout the automated
+ * development pipeline.
+ *
+ * Locale and timezone settings influence not only the language of communication
+ * but also contextual understanding of regulatory requirements, business
+ * practices, and temporal considerations that may affect requirements analysis,
+ * database design, API specifications, and implementation approaches.
+ *
+ * @author Samchon
+ */
 export interface IAutoBeConfig {
     /**
-     * Locale of the A.I. chatbot.
+     * Language and cultural locale preference for AI agent communication.
      *
-     * If you configure this property, the A.I. chatbot will conversate with the
-     * given locale. You can get the locale value by
+     * Configures the language and cultural context for all AI assistant responses
+     * throughout the vibe coding process. When specified, the agent will
+     * communicate in the preferred language while respecting cultural conventions
+     * and linguistic nuances during requirements gathering, progress updates, and
+     * guidance provision.
+     *
+     * The locale setting also influences the agent's understanding of regional
+     * business practices, regulatory considerations, and cultural expectations
+     * that may impact software design decisions and implementation approaches.
+     *
+     * Common formats follow BCP 47 language tags such as "en-US", "ko-KR",
+     * "ja-JP", "zh-CN", "de-DE", etc. Platform-specific detection methods:
      *
      * - Browser: `navigator.language`
-     * - NodeJS: `process.env.LANG.split(".")[0]`
+     * - Node.js: `process.env.LANG.split(".")[0]`
      *
-     * @default your_locale
+     * @default System locale or "en" if unavailable
      */
     locale?: string;
     /**
-     * Timezone of the A.I. chatbot.
+     * Geographic timezone for temporal context and time-sensitive operations.
+     *
+     * Provides timezone awareness for proper handling of time-related
+     * considerations during the vibe coding process. This includes scheduling
+     * references, temporal business logic requirements, timestamp handling in
+     * generated code, and time-based communications that need to be
+     * contextualized for the user's local time.
+     *
+     * Timezone awareness ensures that generated applications properly handle time
+     * zones, that scheduling-related requirements are interpreted correctly, and
+     * that temporal references in documentation and code comments reflect the
+     * user's geographical context.
      *
-     * If you configure this property, the A.I. chatbot will consider the given
-     * timezone. You can get the timezone value by
-     * `Intl.DateTimeFormat().resolvedOptions().timeZone`.
+     * Format follows IANA Time Zone Database identifiers such as
+     * "America/New_York", "Asia/Seoul", "Europe/London", "Pacific/Auckland", etc.
+     * Platform detection: `Intl.DateTimeFormat().resolvedOptions().timeZone`
      *
-     * @default your_timezone
+     * @default System timezone or "UTC" if unavailable
      */
     timezone?: string;
 }

package/lib/structures/IAutoBeProps.d.ts

@@ -2,10 +2,97 @@ import { AutoBeHistory, IAutoBeCompiler } from "@autobe/interface";
 import { ILlmSchema } from "@samchon/openapi";
 import { IAutoBeConfig } from "./IAutoBeConfig";
 import { IAutoBeVendor } from "./IAutoBeVendor";
+/**
+ * Configuration properties for initializing an AutoBeAgent instance.
+ *
+ * This interface defines all the essential parameters required to create and
+ * configure an AutoBeAgent for vibe coding operations. The properties establish
+ * the AI model capabilities, vendor connectivity, compilation infrastructure,
+ * behavioral context, and optional session continuity through conversation
+ * histories.
+ *
+ * The configuration enables type-safe AI function calling through
+ * model-specific schema generation, ensures compatibility with various AI
+ * service providers, and provides the compilation tools necessary for the
+ * sophisticated AST-based development pipeline that transforms conversations
+ * into working software.
+ *
+ * @author Samchon
+ */
 export interface IAutoBeProps<Model extends ILlmSchema.Model> {
+    /**
+     * AI model type specification for type-safe function calling schema
+     * generation.
+     *
+     * Determines the specific AI model schema used for generating function
+     * calling interfaces through
+     * [`typia.llm.application()`](https://typia.io/docs/llm/application). This
+     * type parameter ensures compile-time type safety and enables model-specific
+     * optimizations in the AI function calling interface generation process.
+     *
+     * Common values include "chatgpt" for OpenAI models, "claude" for Anthropic
+     * models, "deepseek" for DeepSeek models, and "llama" for Meta Llama models.
+     * The choice affects function calling capabilities, parameter limitations,
+     * and schema requirements throughout the vibe coding pipeline.
+     *
+     * Note that Google Gemini ("gemini") is not supported due to its lack of
+     * reference types and union types support required for OpenAPI document
+     * composition in the vibe coding process.
+     */
     model: Model;
+    /**
+     * AI vendor configuration for service provider integration.
+     *
+     * Defines the complete AI service connection including the OpenAI SDK
+     * instance, model identifier, request options, and concurrency controls. This
+     * configuration enables the AutoBeAgent to connect with various AI providers
+     * while maintaining consistent functionality across the entire automated
+     * development workflow.
+     *
+     * The vendor settings determine the AI capabilities available for
+     * requirements analysis, database design, API specification, testing, and
+     * implementation phases of the vibe coding process.
+     */
     vendor: IAutoBeVendor;
+    /**
+     * Compilation infrastructure for TypeScript, Prisma, and OpenAPI operations.
+     *
+     * Provides the essential compilation tools required for the sophisticated
+     * AST-based development pipeline. The compiler handles validation,
+     * transformation, and code generation across all development phases including
+     * Prisma schema compilation, OpenAPI document validation, and TypeScript code
+     * compilation.
+     *
+     * For high-performance scenarios with multiple concurrent users, the compiler
+     * can be separated into dedicated worker processes to prevent blocking the
+     * main agent during computationally intensive compilation operations.
+     */
     compiler: IAutoBeCompiler;
+    /**
+     * Optional conversation and development histories for session continuation.
+     *
+     * Enables resuming previous vibe coding sessions by providing the
+     * chronological record of past conversations, development activities, and
+     * generated artifacts. When provided, the agent reconstructs its internal
+     * state from these histories, allowing seamless continuation of development
+     * work.
+     *
+     * This capability supports iterative development workflows where users can
+     * return to modify, enhance, or extend previously generated applications
+     * while maintaining full context of earlier decisions and implementations.
+     */
     histories?: AutoBeHistory[] | undefined;
+    /**
+     * Optional behavioral configuration for localization and context.
+     *
+     * Customizes the agent's communication style, language preferences, and
+     * geographical context to provide personalized vibe coding experiences.
+     * Configuration includes locale settings for internationalized responses and
+     * timezone information for temporal context awareness.
+     *
+     * These settings influence how the agent communicates with users, interprets
+     * regional requirements (such as regulatory considerations), and handles
+     * time-sensitive operations throughout the development process.
+     */
     config?: IAutoBeConfig | undefined;
 }

package/lib/structures/IAutoBeVendor.d.ts

@@ -1,43 +1,85 @@
 import OpenAI from "openai";
 /**
- * LLM service vendor for Agentica Chat.
+ * Interface representing AI vendor configuration for the AutoBeAgent.
  *
- * `IAgenticaVendor` is a type represents an LLM (Large Language Model) vendor
- * of the {@link AutoBeAgent}.
+ * Defines the connection parameters and settings required to integrate with AI
+ * service providers that power the vibe coding pipeline. While utilizing the
+ * OpenAI SDK as the connection interface, this configuration supports various
+ * LLM vendors beyond OpenAI through flexible endpoint and authentication
+ * configuration, enabling integration with Claude, DeepSeek, Meta Llama, and
+ * other providers that follow OpenAI-compatible API patterns.
  *
- * Currently, {@link AutoBeAgent} supports OpenAI SDK. However, it does not mean
- * that you can use only OpenAI's GPT model in the {@link AutoBeAgent}. The
- * OpenAI SDK is just a connection tool to the LLM vendor's API, and you can use
- * other LLM vendors by configuring its `baseURL` and API key.
+ * The vendor configuration determines the AI capabilities available throughout
+ * the entire automated development workflow, from requirements analysis and
+ * database design through API specification, testing, and final implementation.
+ * Different vendors may offer varying performance characteristics, cost
+ * structures, and feature support that can be optimized for specific vibe
+ * coding needs.
  *
- * Therefore, if you want to use another LLM vendor like Claude or Gemini,
- * please configure the `baseURL` to the {@link api}, and set
- * {@link IAutoBeProps.model schema model} as "cluade" or "gemini".
+ * Concurrent request management is built-in to prevent API rate limiting and
+ * optimize resource utilization across multiple development phases and parallel
+ * operations within the vibe coding pipeline.
  *
  * @author Samchon
  */
 export interface IAutoBeVendor {
-    /** OpenAI API instance. */
+    /**
+     * OpenAI SDK instance configured for the target AI vendor.
+     *
+     * Provides the API connection interface used by the AutoBeAgent to
+     * communicate with AI services. While this uses the OpenAI SDK, it can be
+     * configured to connect with various LLM providers by setting the appropriate
+     * `baseURL` and authentication credentials. The SDK serves as a universal
+     * connector that abstracts the underlying API communication protocols.
+     *
+     * For non-OpenAI vendors, configure the SDK with the vendor's API endpoint
+     * and authentication requirements to enable seamless integration with the
+     * vibe coding system.
+     */
     api: OpenAI;
     /**
-     * Chat model to be used.
+     * Specific model identifier to use for AI operations.
+     *
+     * Specifies the exact model name or identifier that should be used for vibe
+     * coding tasks. Supports both official OpenAI chat models and custom model
+     * identifiers for third-party hosting services, cloud providers, or
+     * alternative LLM vendors. The model choice significantly impacts the
+     * quality, performance, and cost of the automated development process.
      *
-     * `({}) & string` means to support third party hosting cloud(eg. openRouter,
-     * aws)
+     * Examples include "gpt-4", "gpt-3.5-turbo" for OpenAI, or vendor-specific
+     * identifiers like "claude-3-sonnet", "deepseek-chat-v3", "llama3.3-70b" when
+     * using alternative providers through compatible APIs.
      */
     model: OpenAI.ChatModel | ({} & string);
-    /** Options for the request. */
+    /**
+     * Optional request configuration for API calls.
+     *
+     * Additional request options that will be applied to all API calls made
+     * through the OpenAI SDK. This can include custom headers, timeouts, retry
+     * policies, or other HTTP client configuration that may be required for
+     * specific vendor integrations or enterprise environments.
+     *
+     * These options provide fine-grained control over the API communication
+     * behavior and can be used to optimize performance or meet specific
+     * infrastructure requirements.
+     */
     options?: OpenAI.RequestOptions | undefined;
     /**
-     * Number of concurrent requests allowed.
+     * Maximum number of concurrent API requests allowed.
+     *
+     * Controls the concurrency level for AI API calls to prevent rate limiting,
+     * manage resource consumption, and optimize system performance. The vibe
+     * coding pipeline may make multiple parallel requests during development
+     * phases, and this setting ensures controlled resource utilization.
      *
-     * If you configure this property, {@link AutoBeAgent} will constrain the
-     * number of concurrent requests to the LLM vendor. If you want to share the
-     * semaphore instance with other agents, you can directly assign the
-     * {@link Semaphore} instance to this property.
+     * A reasonable default provides balanced performance while respecting typical
+     * API rate limits. Lower values reduce resource consumption but may slow
+     * development progress, while higher values can improve performance but risk
+     * hitting rate limits or overwhelming the AI service.
      *
-     * Otherwise, it will not limit the number of concurrent requests, and the
-     * {@link AutoBeAgent} will send requests asynchronously without any limit.
+     * Set to undefined to disable concurrency limiting, allowing unlimited
+     * parallel requests (use with caution based on your API limits and
+     * infrastructure capacity).
      *
      * @default 16
      */

package/lib/utils/backoffRetry.d.ts

@@ -0,0 +1,7 @@
+import { RetryOptions } from "./types/BackoffOptions";
+/**
+ * @param fn Function to Apply the retry logic.
+ * @param maxRetries How many time to try. Max Retry is 5.
+ * @returns
+ */
+export declare function randomBackoffRetry<T>(fn: () => Promise<T>, options?: Partial<RetryOptions>): Promise<T>;

package/lib/utils/backoffRetry.js

@@ -0,0 +1,73 @@
+"use strict";
+var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, generator) {
+    function adopt(value) { return value instanceof P ? value : new P(function (resolve) { resolve(value); }); }
+    return new (P || (P = Promise))(function (resolve, reject) {
+        function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }
+        function rejected(value) { try { step(generator["throw"](value)); } catch (e) { reject(e); } }
+        function step(result) { result.done ? resolve(result.value) : adopt(result.value).then(fulfilled, rejected); }
+        step((generator = generator.apply(thisArg, _arguments || [])).next());
+    });
+};
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.randomBackoffRetry = randomBackoffRetry;
+/**
+ * @param fn Function to Apply the retry logic.
+ * @param maxRetries How many time to try. Max Retry is 5.
+ * @returns
+ */
+function randomBackoffRetry(fn_1) {
+    return __awaiter(this, arguments, void 0, function* (fn, options = {}) {
+        const { maxRetries = 5, baseDelay = 4000, maxDelay = 60000, jitter = 0.8, handleError = isRetryError, } = options;
+        let lastError;
+        for (let attempt = 0; attempt < maxRetries; attempt++) {
+            try {
+                return yield fn();
+            }
+            catch (err) {
+                lastError = err;
+                if (attempt === maxRetries - 1)
+                    throw err;
+                if (!handleError(err))
+                    throw err;
+                const tempDelay = Math.min(baseDelay * 2 ** attempt, maxDelay);
+                const delay = tempDelay * (1 + Math.random() * jitter);
+                yield new Promise((res) => setTimeout(res, delay));
+            }
+        }
+        throw lastError;
+    });
+}
+function isRetryError(error) {
+    var _a, _b, _c;
+    // 1) Quota exceeded → No retry
+    if ((error === null || error === void 0 ? void 0 : error.code) === "insufficient_quota" ||
+        ((_a = error === null || error === void 0 ? void 0 : error.error) === null || _a === void 0 ? void 0 : _a.type) === "insufficient_quota") {
+        return false;
+    }
+    // 2) 5xx / server_error → Retry
+    if ((typeof (error === null || error === void 0 ? void 0 : error.status) === "number" && error.status >= 500) ||
+        ((_b = error === null || error === void 0 ? void 0 : error.error) === null || _b === void 0 ? void 0 : _b.type) === "server_error") {
+        return true;
+    }
+    // 3) HTTP 429
+    if ((error === null || error === void 0 ? void 0 : error.status) === 429) {
+        return true;
+    }
+    // 4) undici / network related
+    const code = (error === null || error === void 0 ? void 0 : error.code) || ((_c = error === null || error === void 0 ? void 0 : error.cause) === null || _c === void 0 ? void 0 : _c.code);
+    if ([
+        "UND_ERR_SOCKET",
+        "UND_ERR_CONNECT_TIMEOUT",
+        "ETIMEDOUT",
+        "ECONNRESET",
+        "EPIPE",
+    ].includes(code)) {
+        return true;
+    }
+    // 5) fetch abort
+    if ((error === null || error === void 0 ? void 0 : error.message) === "terminated" || (error === null || error === void 0 ? void 0 : error.name) === "AbortError") {
+        return true;
+    }
+    return false;
+}
+//# sourceMappingURL=backoffRetry.js.map

package/lib/utils/backoffRetry.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"backoffRetry.js","sourceRoot":"","sources":["../../src/utils/backoffRetry.ts"],"names":[],"mappings":";;;;;;;;;;;AAOA,gDAgCC;AArCD;;;;GAIG;AACH,SAAsB,kBAAkB;yDACtC,EAAoB,EACpB,UAAiC,EAAE;QAEnC,MAAM,EACJ,UAAU,GAAG,CAAC,EACd,SAAS,GAAG,IAAK,EACjB,QAAQ,GAAG,KAAM,EACjB,MAAM,GAAG,GAAG,EACZ,WAAW,GAAG,YAAY,GAC3B,GAAG,OAAO,CAAC;QAEZ,IAAI,SAAkB,CAAC;QAEvB,KAAK,IAAI,OAAO,GAAG,CAAC,EAAE,OAAO,GAAG,UAAU,EAAE,OAAO,EAAE,EAAE,CAAC;YACtD,IAAI,CAAC;gBACH,OAAO,MAAM,EAAE,EAAE,CAAC;YACpB,CAAC;YAAC,OAAO,GAAG,EAAE,CAAC;gBACb,SAAS,GAAG,GAAG,CAAC;gBAEhB,IAAI,OAAO,KAAK,UAAU,GAAG,CAAC;oBAAE,MAAM,GAAG,CAAC;gBAE1C,IAAI,CAAC,WAAW,CAAC,GAAG,CAAC;oBAAE,MAAM,GAAG,CAAC;gBAEjC,MAAM,SAAS,GAAG,IAAI,CAAC,GAAG,CAAC,SAAS,GAAG,CAAC,IAAI,OAAO,EAAE,QAAQ,CAAC,CAAC;gBAC/D,MAAM,KAAK,GAAG,SAAS,GAAG,CAAC,CAAC,GAAG,IAAI,CAAC,MAAM,EAAE,GAAG,MAAM,CAAC,CAAC;gBAEvD,MAAM,IAAI,OAAO,CAAC,CAAC,GAAG,EAAE,EAAE,CAAC,UAAU,CAAC,GAAG,EAAE,KAAK,CAAC,CAAC,CAAC;YACrD,CAAC;QACH,CAAC;QAED,MAAM,SAAS,CAAC;IAClB,CAAC;CAAA;AAED,SAAS,YAAY,CAAC,KAAU;;IAC9B,+BAA+B;IAC/B,IACE,CAAA,KAAK,aAAL,KAAK,uBAAL,KAAK,CAAE,IAAI,MAAK,oBAAoB;QACpC,CAAA,MAAA,KAAK,aAAL,KAAK,uBAAL,KAAK,CAAE,KAAK,0CAAE,IAAI,MAAK,oBAAoB,EAC3C,CAAC;QACD,OAAO,KAAK,CAAC;IACf,CAAC;IAED,gCAAgC;IAChC,IACE,CAAC,OAAO,CAAA,KAAK,aAAL,KAAK,uBAAL,KAAK,CAAE,MAAM,CAAA,KAAK,QAAQ,IAAI,KAAK,CAAC,MAAM,IAAI,GAAG,CAAC;QAC1D,CAAA,MAAA,KAAK,aAAL,KAAK,uBAAL,KAAK,CAAE,KAAK,0CAAE,IAAI,MAAK,cAAc,EACrC,CAAC;QACD,OAAO,IAAI,CAAC;IACd,CAAC;IAED,cAAc;IACd,IAAI,CAAA,KAAK,aAAL,KAAK,uBAAL,KAAK,CAAE,MAAM,MAAK,GAAG,EAAE,CAAC;QAC1B,OAAO,IAAI,CAAC;IACd,CAAC;IAED,8BAA8B;IAC9B,MAAM,IAAI,GAAG,CAAA,KAAK,aAAL,KAAK,uBAAL,KAAK,CAAE,IAAI,MAAI,MAAA,KAAK,aAAL,KAAK,uBAAL,KAAK,CAAE,KAAK,0CAAE,IAAI,CAAA,CAAC;IAC/C,IACE;QACE,gBAAgB;QAChB,yBAAyB;QACzB,WAAW;QACX,YAAY;QACZ,OAAO;KACR,CAAC,QAAQ,CAAC,IAAI,CAAC,EAChB,CAAC;QACD,OAAO,IAAI,CAAC;IACd,CAAC;IAED,iBAAiB;IACjB,IAAI,CAAA,KAAK,aAAL,KAAK,uBAAL,KAAK,CAAE,OAAO,MAAK,YAAY,IAAI,CAAA,KAAK,aAAL,KAAK,uBAAL,KAAK,CAAE,IAAI,MAAK,YAAY,EAAE,CAAC;QACpE,OAAO,IAAI,CAAC;IACd,CAAC;IAED,OAAO,KAAK,CAAC;AACf,CAAC"}

package/lib/utils/types/BackoffOptions.d.ts

@@ -0,0 +1,12 @@
+export interface RetryOptions {
+    /** Maximum number of retry attempts (default: 5) */
+    maxRetries: number;
+    /** Base delay in milliseconds (default: 2000) */
+    baseDelay: number;
+    /** Maximum delay in milliseconds (default: 60_000) */
+    maxDelay: number;
+    /** Jitter factor for randomization (0-1, default: 0.3) */
+    jitter: number;
+    /** Function to determine if error should trigger retry (default: isRetryError) */
+    handleError: (error: any) => boolean;
+}

package/lib/utils/types/BackoffOptions.js

@@ -0,0 +1,3 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+//# sourceMappingURL=BackoffOptions.js.map

package/lib/utils/types/BackoffOptions.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"BackoffOptions.js","sourceRoot":"","sources":["../../../src/utils/types/BackoffOptions.ts"],"names":[],"mappings":""}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@autobe/agent",
-  "version": "0.8.0",
+  "version": "0.9.0",
   "description": "AI backend server code generator",
   "main": "lib/index.js",
   "author": "Wrtn Technologies",
@@ -30,7 +30,7 @@
     "tstl": "^3.0.0",
     "typia": "^9.3.1",
     "uuid": "^11.1.0",
-    "@autobe/interface": "^0.8.0"
+    "@autobe/interface": "^0.9.0"
   },
   "devDependencies": {
     "@rollup/plugin-terser": "^0.4.4",
@@ -43,8 +43,8 @@
     "ts-node": "^10.9.2",
     "ts-patch": "^3.3.0",
     "typescript": "~5.8.3",
-    "@autobe/filesystem": "^0.8.0",
-    "@autobe/compiler": "^0.8.0"
+    "@autobe/compiler": "^0.9.0",
+    "@autobe/filesystem": "^0.9.0"
   },
   "keywords": [
     "ai",