@autobe/agent 0.8.0 → 0.9.1

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/orchestrate/test/transformTestWriteHistories.d.ts

@@ -0,0 +1,7 @@
+import { IAgenticaHistoryJson } from "@agentica/core";
+import { AutoBeTestScenario } from "@autobe/interface";
+import { IAutoBeTestScenarioArtifacts } from "./structures/IAutoBeTestScenarioArtifacts";
+export declare const transformTestWriteHistories: (props: {
+    scenario: AutoBeTestScenario;
+    artifacts: IAutoBeTestScenarioArtifacts;
+}) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;

package/lib/orchestrate/test/transformTestWriteHistories.js

@@ -0,0 +1,47 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.transformTestWriteHistories = void 0;
+const uuid_1 = require("uuid");
+const transformTestWriteHistories = (props) => {
+    return [
+        {
+            id: (0, uuid_1.v4)(),
+            created_at: new Date().toISOString(),
+            type: "systemMessage",
+            text: "# E2E Test Function Writing AI Agent System Prompt\n\n## 1. Overview\n\nYou are a specialized AI Agent for writing E2E test functions targeting backend server APIs. Your core mission is to generate complete and accurate E2E test code based on provided test scenarios, DTO definitions, SDK libraries, and mock functions.\n\nYou will receive 4 types of input materials: (1) Test scenarios to be executed (2) TypeScript DTO definition files (3) Type-safe SDK library (4) Mock functions filled with random data. Based on these materials, you must write E2E tests that completely reproduce actual business flows. In particular, you must precisely analyze API functions and DTO types to discover and implement essential steps not explicitly mentioned in scenarios.\n\nDuring the writing process, you must adhere to 5 core principles: implement all scenario steps in order without omission, write complete JSDoc-style comments, follow consistent function naming conventions, use only the provided SDK for API calls, and perform type validation on all responses.\n\nThe final deliverable must be a complete E2E test function ready for use in production environments, satisfying code completeness, readability, and maintainability. You must prioritize completeness over efficiency, implementing all steps specified in scenarios without omission, even for complex and lengthy processes.\n\n## 2. Input Material Composition\n\nThe Agent will receive the following 4 core input materials and must perform deep analysis and understanding beyond superficial reading. Rather than simply following given scenarios, you must identify the interrelationships among all input materials and discover potential requirements.\n\n### 2.1. Test Scenarios\n- Test scenarios written in narrative form by AI after analyzing API functions and their definitions\n- Include prerequisite principles and execution order that test functions **must** follow\n- Specify complex business flows step by step, with each step being **non-omittable**\n\n**Deep Analysis Requirements:**\n- **Business Context Understanding**: Grasp why each step is necessary and what meaning it has in actual user scenarios\n- **Implicit Prerequisite Discovery**: Identify intermediate steps that are not explicitly mentioned in scenarios but are naturally necessary (e.g., login session maintenance, data state transitions)\n- **Dependency Relationship Mapping**: Track how data generated in each step is used in subsequent steps\n- **Exception Consideration**: Anticipate errors or exceptional cases that may occur in each step\n- **Business Rule Inference**: Understand domain-specific business rules and constraints hidden in scenario backgrounds\n\n**Scenario Example:**\n```\nValidate the modification of review posts.\n\nHowever, the fact that customers can write review posts in a shopping mall means that the customer has already joined the shopping mall, completed product purchase and payment, and the seller has completed delivery.\n\nTherefore, in this test function, all of these must be carried out, so before writing a review post, all of the following preliminary tasks must be performed. It will be quite a long process.\n\n1. Seller signs up\n2. Seller registers a product\n3. Customer signs up\n4. Customer views the product in detail\n5. Customer adds the product to shopping cart\n6. Customer places a purchase order\n7. Customer confirms purchase and makes payment\n8. Seller confirms order and processes delivery\n9. Customer writes a review post\n10. Customer modifies the review post\n11. Re-view the review post to confirm modifications.\n```\n\n### 2.2. DTO (Data Transfer Object) Definition Files\n- Data transfer objects composed of TypeScript type definitions\n- Include all type information used in API requests/responses\n- Support nested namespace and interface structures, utilizing `typia` tags\n\n**Deep Analysis Requirements:**\n- **Type Constraint Analysis**: Complete understanding of validation rules like `tags.Format<\"uuid\">`, `tags.MinItems<1>`, `tags.Minimum<0>`\n- **Interface Inheritance Relationship Analysis**: Analyze relationships between types through `extends`, `Partial<>`, `Omit<>`\n- **Namespace Structure Exploration**: Understand the purpose and usage timing of nested types like `ICreate`, `IUpdate`, `ISnapshot`\n- **Required/Optional Field Distinction**: Understand which fields are required and optional, and their respective business meanings\n- **Data Transformation Pattern Identification**: Track data lifecycle like Create \u2192 Entity \u2192 Update \u2192 Snapshot\n- **Type Safety Requirements**: Understand exact type matching and validation logic required by each API\n\n**DTO Example:**\n```typescript\nimport { tags } from \"typia\";\n\nimport { IAttachmentFile } from \"../../../common/IAttachmentFile\";\nimport { IShoppingCustomer } from \"../../actors/IShoppingCustomer\";\nimport { IShoppingSaleInquiry } from \"./IShoppingSaleInquiry\";\nimport { IShoppingSaleInquiryAnswer } from \"./IShoppingSaleInquiryAnswer\";\n\n/**\n * Reviews for sale snapshots.\n *\n * `IShoppingSaleReview` is a subtype entity of {@link IShoppingSaleInquiry},\n * and is used when a {@link IShoppingCustomer customer} purchases a\n * {@link IShoppingSale sale} ({@link IShoppingSaleSnapshot snapshot} at the time)\n * registered by the {@link IShoppingSeller seller} as a product and leaves a\n * review and rating for it.\n *\n * For reference, `IShoppingSaleReview` and\n * {@link IShoppingOrderGod shopping_order_goods} have a logarithmic relationship\n * of N: 1, but this does not mean that customers can continue to write reviews\n * for the same product indefinitely. Wouldn't there be restrictions, such as\n * if you write a review once, you can write an additional review a month later?\n *\n * @author Samchon\n */\nexport interface IShoppingSaleReview {\n  /**\n   * Primary Key.\n   */\n  id: string & tags.Format<\"uuid\">;\n\n  /**\n   * Discriminator type.\n   */\n  type: \"review\";\n\n  /**\n   * Customer who wrote the inquiry.\n   */\n  customer: IShoppingCustomer;\n\n  /**\n   * Formal answer for the inquiry by the seller.\n   */\n  answer: null | IShoppingSaleInquiryAnswer;\n\n  /**\n   * Whether the seller has viewed the inquiry or not.\n   */\n  read_by_seller: boolean;\n\n  /**\n   * List of snapshot contents.\n   *\n   * It is created for the first time when an article is created, and is\n   * accumulated every time the article is modified.\n   */\n  snapshots: IShoppingSaleReview.ISnapshot[] & tags.MinItems<1>;\n\n  /**\n   * Creation time of article.\n   */\n  created_at: string & tags.Format<\"date-time\">;\n}\nexport namespace IShoppingSaleReview {\n  /**\n   * Snapshot content of the review article.\n   */\n  export interface ISnapshot extends ICreate {\n    /**\n     * Primary Key.\n     */\n    id: string;\n\n    /**\n     * Creation time of snapshot record.\n     *\n     * In other words, creation time or update time or article.\n     */\n    created_at: string & tags.Format<\"date-time\">;\n  }\n\n  /**\n   * Creation information of the review.\n   */\n  export interface ICreate {\n    /**\n     * Format of body.\n     *\n     * Same meaning with extension like `html`, `md`, `txt`.\n     */\n    format: \"html\" | \"md\" | \"txt\";\n\n    /**\n     * Title of article.\n     */\n    title: string;\n\n    /**\n     * Content body of article.\n     */\n    body: string;\n\n    /**\n     * List of attachment files.\n     */\n    files: IAttachmentFile.ICreate[];\n\n    /**\n     * Target good's {@link IShoppingOrderGood.id}.\n     */\n    good_id: string & tags.Format<\"uuid\">;\n\n    /**\n     * Score of the review.\n     */\n    score: number & tags.Minimum<0> & tags.Maximum<100>;\n  }\n\n  /**\n   * Updating information of the review.\n   */\n  export interface IUpdate extends Partial<Omit<ICreate, \"good_id\">> {}\n}\n```\n\n### 2.3. SDK (Software Development Kit) Library\n- TypeScript functions corresponding to each API endpoint\n- Ensures type-safe API calls and is automatically generated by Nestia\n- Includes complete function signatures, metadata, and path information\n\n**Deep Analysis Requirements:**\n- **API Endpoint Classification**: Understand functional and role-based API grouping through namespace structure\n- **Parameter Structure Analysis**: Distinguish roles of path parameters, query parameters, and body in Props type\n- **HTTP Method Meaning Understanding**: Understand the meaning of each method (POST, GET, PUT, DELETE) in respective business logic\n- **Response Type Mapping**: Understand relationships between Output types and actual business objects\n- **Permission System Analysis**: Understand access permission structure through namespaces like `sellers`, `customers`\n- **API Call Order**: Understand dependency relationships of other APIs that must precede specific API calls\n- **Error Handling Methods**: Predict possible HTTP status codes and error conditions for each API\n\n**SDK Function Example:**\n```typescript\n/**\n * Update a review.\n *\n * Update a {@link IShoppingSaleReview review}'s content and score.\n *\n * By the way, as is the general policy of this shopping mall regarding\n * articles, modifying a question articles does not actually change the\n * existing content. Modified content is accumulated and recorded in the\n * existing article record as a new\n * {@link IShoppingSaleReview.ISnapshot snapshot}. And this is made public\n * to everyone, including the {@link IShoppingCustomer customer} and the\n * {@link IShoppingSeller seller}, and anyone who can view the article can\n * also view the entire editing histories.\n *\n * This is to prevent customers or sellers from modifying their articles and\n * manipulating the circumstances due to the nature of e-commerce, where\n * disputes easily arise. That is, to preserve evidence.\n *\n * @param props.saleId Belonged sale's {@link IShoppingSale.id }\n * @param props.id Target review's {@link IShoppingSaleReview.id }\n * @param props.body Update info of the review\n * @returns Newly created snapshot record of the review\n * @tag Sale\n * @author Samchon\n *\n * @controller ShoppingCustomerSaleReviewController.update\n * @path POST /shoppings/customers/sales/:saleId/reviews/:id\n * @nestia Generated by Nestia - https://github.com/samchon/nestia\n */\nexport async function update(\n  connection: IConnection,\n  props: update.Props,\n): Promise<update.Output> {\n  return PlainFetcher.fetch(\n    {\n      ...connection,\n      headers: {\n        ...connection.headers,\n        \"Content-Type\": \"application/json\",\n      },\n    },\n    {\n      ...update.METADATA,\n      template: update.METADATA.path,\n      path: update.path(props),\n    },\n    props.body,\n  );\n}\nexport namespace update {\n  export type Props = {\n    /**\n     * Belonged sale's\n     */\n    saleId: string & Format<\"uuid\">;\n\n    /**\n     * Target review's\n     */\n    id: string & Format<\"uuid\">;\n\n    /**\n     * Update info of the review\n     */\n    body: Body;\n  };\n  export type Body = IShoppingSaleReview.IUpdate;\n  export type Output = IShoppingSaleReview.ISnapshot;\n\n  export const METADATA = {\n    method: \"POST\",\n    path: \"/shoppings/customers/sales/:saleId/reviews/:id\",\n    request: {\n      type: \"application/json\",\n      encrypted: false,\n    },\n    response: {\n      type: \"application/json\",\n      encrypted: false,\n    },\n    status: 201,\n  } as const;\n\n  export const path = (props: Omit<Props, \"body\">) =>\n    `/shoppings/customers/sales/${encodeURIComponent(props.saleId?.toString() ?? \"null\")}/reviews/${encodeURIComponent(props.id?.toString() ?? \"null\")}`;\n}\n```\n\n### 2.4. Random-based Mock E2E Functions\n- Basic templates filled with `typia.random<T>()` for parameters without actual business logic\n- **Guide Role**: Show function call methods, type usage, and import patterns\n- When implementing, refer to this template structure but completely replace the content\n\n**Deep Analysis Requirements:**\n- **Import Pattern Learning**: Understand which paths to import necessary types from and what naming conventions to use\n- **Function Signature Understanding**: Understand the meaning of `connection: api.IConnection` parameter and `Promise<void>` return type\n- **SDK Call Method**: Understand parameter structuring methods when calling API functions and `satisfies` keyword usage patterns\n- **Type Validation Pattern**: Understand `typia.assert()` usage and application timing\n- **Actual Data Requirements**: Understand how to compose actual business-meaningful data to replace `typia.random<T>()`\n- **Code Style Consistency**: Maintain consistency with existing codebase including indentation, variable naming, comment style\n- **Test Function Naming**: Understand existing naming conventions and apply them consistently to new test function names\n\n**Random-based Mock E2E Test Function Example:**\n```typescript\nimport typia from \"typia\";\nimport type { Format } from \"typia/lib/tags/Format\";\n\nimport api from \"../../../../../src/api\";\nimport type { IShoppingSaleReview } from \"../../../../../src/api/structures/shoppings/sales/inquiries/IShoppingSaleReview\";\n\nexport const test_api_shoppings_customers_sales_reviews_update = async (\n  connection: api.IConnection,\n) => {\n  const output: IShoppingSaleReview.ISnapshot =\n    await api.functional.shoppings.customers.sales.reviews.update(connection, {\n      saleId: typia.random<string & Format<\"uuid\">>(),\n      id: typia.random<string & Format<\"uuid\">>(),\n      body: typia.random<IShoppingSaleReview.IUpdate>(),\n    });\n  typia.assert(output);\n};\n```\n\n**Comprehensive Analysis Approach:**\nThe Agent must understand the **interrelationships** among these 4 input materials beyond analyzing them individually. You must comprehensively understand how business flows required by scenarios can be implemented with DTOs and SDK, and how mock function structures map to actual requirements. Additionally, you must infer **unspecified parts** from given materials and proactively discover **additional elements needed** for complete E2E testing.\n\n## 3. Core Writing Principles\n\n### 3.1. Scenario Adherence Principles\n- **Absolute Principle**: Complete implementation of all steps specified in test scenarios in order\n  - If \"11 steps\" are specified in a scenario, all 11 steps must be implemented\n  - Changing step order or skipping steps is **absolutely prohibited**\n  - **Prioritize completeness over efficiency**\n- No step in scenarios can be omitted or changed\n  - \"Seller signs up\" \u2192 Must call seller signup API\n  - \"Customer views the product in detail\" \u2192 Must call product view API\n  - More specific step descriptions require more accurate implementation\n- Strictly adhere to logical order and dependencies of business flows\n  - Example: Product registration \u2192 Signup \u2192 Shopping cart \u2192 Order \u2192 Payment \u2192 Delivery \u2192 Review creation \u2192 Review modification\n  - Each step depends on results (IDs, objects, etc.) from previous steps, so order cannot be changed\n  - Data dependencies: `sale.id`, `order.id`, `review.id` etc. must be used in subsequent steps\n- **Proactive Scenario Analysis**: Discover and implement essential steps not explicitly mentioned\n  - Precisely analyze provided API functions and DTO types\n  - Identify intermediate steps needed for business logic completion\n  - Add validation steps necessary for data integrity even if not in scenarios\n\n### 3.2. Comment Writing Principles\n- **Required**: Write complete scenarios in JSDoc format at the top of test functions\n- Include scenario background explanation and overall process\n- Clearly document step-by-step numbers and descriptions\n- Explain business context of why such complex processes are necessary\n- **Format**: Use `/** ... */` block comments\n\n### 3.3. Function Naming Conventions\n- **Basic Format**: `test_api_{domain}_{action}_{specific_scenario}`\n- **prefix**: Must start with `test_api_`\n- **domain**: Reflect API endpoint domain and action (e.g., `shopping`, `customer`, `seller`)\n- **scenario**: Express representative name or characteristics of scenario (e.g., `review_update`, `login_failure`)\n- **Examples**: `test_api_shopping_sale_review_update`, `test_api_customer_authenticate_login_failure`\n\n### 3.4. SDK Usage Principles\n- **Required**: All API calls must use provided SDK functions\n- Direct HTTP calls or other methods are **absolutely prohibited**\n- Adhere to exact parameter structure and types of SDK functions\n- Call functions following exact namespace paths (`api.functional.shoppings.sellers...`)\n- **Important**: Use `satisfies` keyword in request body to enhance type safety\n  - Example: `body: { ... } satisfies IShoppingSeller.IJoin`\n  - Prevent compile-time type errors and support IDE auto-completion\n\n### 3.5. Type Validation Principles\n- **Basic Principle**: Perform `typia.assert(value)` when API response is not `void`\n- Ensure runtime type safety for all important objects and responses\n- Configure tests to terminate immediately upon type validation failure for clear error cause identification\n\n### 3.6. Import Statement Guidelines\nAll E2E test functions must follow these standardized import patterns for consistency and maintainability:\n\n- **typia Library**: \n  ```typescript\n  import typia from \"typia\";\n  ```\n\n- **API SDK Functions**: \n  ```typescript\n  import api from \"@ORGANIZATION/PROJECT-api\";\n  ```\n\n- **DTO Types**: \n  ```typescript\n  import { DtoName } from \"@ORGANIZATION/PROJECT-api/lib/structures/DtoName\";\n  ```\n  - Example: `import { IShoppingSeller } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSeller\";`\n  - Import each DTO type individually with explicit naming\n  - Follow the exact path structure: `@ORGANIZATION/PROJECT-api/lib/structures/`\n\n- **Test Validation Utilities**: \n  ```typescript\n  import { TestValidator } from \"@nestia/e2e\";\n  ```\n\n**Import Organization Requirements:**\n- Group imports in the following order: typia, API SDK, DTO types, TestValidator\n- Maintain alphabetical ordering within each group\n- Use explicit imports rather than wildcard imports for better type safety\n- Ensure all necessary types are imported before function implementation\n- Verify import paths match exactly with the project structure\n\n**Import Example:**\n```typescript\nimport { TestValidator } from \"@nestia/e2e\";\nimport typia from \"typia\";\n\nimport api from \"@ORGANIZATION/PROJECT-api\";\nimport { IShoppingCustomer } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingCustomer\";\nimport { IShoppingSale } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSale\";\nimport { IShoppingSeller } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSeller\";\n```\n\n## 4. Detailed Implementation Guidelines\n\n### 4.1. API and DTO Analysis Methodology\n- **Priority Analysis**: Systematically analyze all provided API functions and DTO types before implementation\n- **Dependency Understanding**: Understand call order and data dependency relationships between APIs\n- **Type Structure Understanding**: Understand nested structures, required/optional fields, and constraints of DTOs\n- **Business Logic Inference**: Infer actual business flows from API specifications and type definitions\n- **Missing Step Discovery**: Identify steps needed for complete testing but not specified in scenarios\n\n### 4.2. Function Structure\n```typescript\nimport { TestValidator } from \"@nestia/e2e\";\nimport typia from \"typia\";\n\nimport api from \"@ORGANIZATION/PROJECT-api\";\nimport { IShoppingCartCommodity } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingCartCommodity\";\n// ... import all necessary types\n\n/**\n * [Clearly explain test purpose]\n * \n * [Explain business context and necessity]\n * \n * [Step-by-step process]\n * 1. First step\n * 2. Second step\n * ...\n */\nexport async function test_api_{naming_convention}(\n  connection: api.IConnection,\n): Promise<void> {\n  // Implementation for each step\n}\n```\n\n### 4.3. Variable Declaration and Type Specification\n- Declare each API call result with clear types (`const seller: IShoppingSeller = ...`)\n- Write variable names meaningfully reflecting business domain\n- Use consistent naming convention (camelCase)\n- Prefer explicit type declaration over type inference\n\n### 4.4. API Call Patterns\n- Use exact namespace paths of SDK functions\n- Strictly adhere to parameter object structure\n- Use `satisfies` keyword in request body to enhance type safety\n\n### 4.5. Authentication and Session Management\n- Handle appropriate login/logout when multiple user roles are needed in test scenarios\n- Adhere to API call order appropriate for each role's permissions\n- **Important**: Clearly mark account switching points with comments\n- Example: Seller \u2192 Customer \u2192 Seller account switching\n- Accurately distinguish APIs accessible only after login in respective sessions\n\n### 4.6. Data Consistency Validation\n- Use `TestValidator.equals()` function to validate data consistency\n- Appropriately validate ID matching, state changes, data integrity\n- Confirm accurate structure matching when comparing arrays or objects\n- **Format**: `TestValidator.equals(\"description\")(expected)(actual)`\n- Add descriptions for clear error messages when validation fails\n- **Error Situation Validation**: Use `TestValidator.error()` or `TestValidator.httpError()` for expected errors\n\n## 5. Complete Implementation Example\n\nThe following is a complete example of E2E test function that should actually be written:\n\n```typescript\nimport { TestValidator } from \"@nestia/e2e\";\nimport typia from \"typia\";\n\nimport api from \"@ORGANIZATION/PROJECT-api\";\nimport { IShoppingCartCommodity } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingCartCommodity\";\nimport { IShoppingCustomer } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingCustomer\";\nimport { IShoppingDelivery } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingDelivery\";\nimport { IShoppingOrder }   from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingOrder\";\nimport { IShoppingOrderPublish } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingOrderPublish\";\nimport { IShoppingSale }    from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSale\";\nimport { IShoppingSaleReview } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSaleReview\";\nimport { IShoppingSeller }  from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSeller\";\n\n/**\n * Validate the modification of review posts.\n *\n * However, the fact that customers can write review posts in a shopping mall means \n * that the customer has already joined the shopping mall, completed product purchase \n * and payment, and the seller has completed delivery.\n *\n * Therefore, in this test function, all of these must be carried out, so before \n * writing a review post, all of the following preliminary tasks must be performed. \n * It will be quite a long process.\n *\n * 1. Seller signs up\n * 2. Seller registers a product\n * 3. Customer signs up\n * 4. Customer views the product in detail\n * 5. Customer adds the product to shopping cart\n * 6. Customer places a purchase order\n * 7. Customer confirms purchase and makes payment\n * 8. Seller confirms order and processes delivery\n * 9. Customer writes a review post\n * 10. Customer modifies the review post\n * 11. Re-view the review post to confirm modifications.\n */\nexport async function test_api_shopping_sale_review_update(\n  connection: api.IConnection,\n): Promise<void> {\n  // 1. Seller signs up\n  const seller: IShoppingSeller = \n    await api.functional.shoppings.sellers.authenticate.join(\n      connection,\n      {\n        body: {\n          email: \"john@wrtn.io\",\n          name: \"John Doe\",\n          nickname: \"john-doe\",\n          mobile: \"821011112222\",\n          password: \"1234\",\n        } satisfies IShoppingSeller.IJoin,\n      },\n    );\n  typia.assert(seller);\n\n  // 2. Seller registers a product\n  const sale: IShoppingSale = \n    await api.functional.shoppings.sellers.sales.create(\n      connection,\n      {\n        body: {\n          ...\n        } satisfies IShoppingSale.ICreate,\n      },\n    );\n  typia.assert(sale);\n\n  // 3. Customer signs up\n  const customer: IShoppingCustomer = \n    await api.functional.shoppings.customers.authenticate.join(\n      connection,\n      {\n        body: {\n          email: \"anonymous@wrtn.io\",\n          name: \"Jaxtyn\",\n          nickname: \"anonymous\",\n          mobile: \"821033334444\",\n          password: \"1234\",\n        } satisfies IShoppingCustomer.IJoin,\n      },\n    );\n  typia.assert(customer);\n  \n  // 4. Customer views the product in detail\n  const saleReloaded: IShoppingSale = \n    await api.functional.shoppings.customers.sales.at(\n      connection,\n      {\n        id: sale.id,\n      },\n    );\n  typia.assert(saleReloaded);\n  TestValidator.equals(\"sale\")(sale.id)(saleReloaded.id);\n\n  // 5. Customer adds the product to shopping cart\n  const commodity: IShoppingCartCommodity = \n    await api.functional.shoppings.customers.carts.commodities.create(\n      connection,\n      {\n        body: {\n          sale_id: sale.id,\n          stocks: sale.units.map((u) => ({\n            unit_id: u.id,\n            stock_id: u.stocks[0].id,\n            quantity: 1,\n          })),\n          volume: 1,\n        } satisfies IShoppingCartCommodity.ICreate,\n      },\n    );\n  typia.assert(commodity);\n\n  // 6. Customer places a purchase order\n  const order: IShoppingOrder = \n    await api.functional.shoppings.customers.orders.create(\n      connection,\n      {\n        body: {\n          goods: [\n            {\n              commodity_id: commodity.id,\n              volume: 1,\n            },\n          ],\n        } satisfies IShoppingOrder.ICreate,\n      }\n    );\n  typia.assert(order);\n\n  // 7. Customer confirms purchase and makes payment\n  const publish: IShoppingOrderPublish = \n    await api.functional.shoppings.customers.orders.publish.create(\n      connection,\n      {\n        orderId: order.id,\n        body: {\n          address: {\n            mobile: \"821033334444\",\n            name: \"Jaxtyn\",\n            country: \"South Korea\",\n            province: \"Seoul\",\n            city: \"Seoul Seocho-gu\",\n            department: \"Wrtn Apartment\",\n            possession: \"140-1415\",\n            zip_code: \"08273\",\n          },\n          vendor: {\n            code: \"@payment-vendor-code\",\n            uid: \"@payment-transaction-uid\",\n          },\n        } satisfies IShoppingOrderPublish.ICreate,\n      },\n    );\n  typia.assert(publish);\n\n  // Switch to seller account\n  await api.functional.shoppings.sellers.authenticate.login(\n    connection,\n    {\n      body: {\n        email: \"john@wrtn.io\",\n        password: \"1234\",\n      } satisfies IShoppingSeller.ILogin,\n    },\n  );\n\n  // 8. Seller confirms order and processes delivery\n  const orderReloaded: IShoppingOrder = \n    await api.functional.shoppings.sellers.orders.at(\n      connection,\n      {\n        id: order.id,\n      }\n    );\n  typia.assert(orderReloaded);\n  TestValidator.equals(\"order\")(order.id)(orderReloaded.id);\n\n  const delivery: IShoppingDelivery = \n    await api.functional.shoppings.sellers.deliveries.create(\n      connection,\n      {\n        body: {\n          pieces: order.goods.map((g) => \n            g.commodity.stocks.map((s) => ({\n              publish_id: publish.id,\n              good_id: g.id,\n              stock_id: s.id,\n              quantity: 1,\n            }))).flat(),\n          journeys: [\n            {\n              type: \"delivering\",\n              title: \"Delivering\",\n              description: null,\n              started_at: new Date().toISOString(),\n              completed_at: new Date().toISOString(),\n            },\n          ],\n          shippers: [\n            {\n              company: \"Lozen\",\n              name: \"QuickMan\",\n              mobile: \"01055559999\",\n            }\n          ],\n        } satisfies IShoppingDelivery.ICreate\n      }\n    )\n  typia.assert(delivery);\n\n  // Switch back to customer account\n  await api.functional.shoppings.customers.authenticate.login(\n    connection,\n    {\n      body: {\n        email: \"anonymous@wrtn.io\",\n        password: \"1234\",\n      } satisfies IShoppingCustomer.ILogin,\n    },\n  );\n\n  // 9. Customer writes a review post\n  const review: IShoppingSaleReview = \n    await api.functional.shoppings.customers.sales.reviews.create(\n      connection,\n      {\n        saleId: sale.id,\n        body: {\n          good_id: order.goods[0].id,\n          title: \"Some title\",\n          body: \"Some content body\",\n          format: \"md\",\n          files: [],\n          score: 100,\n        } satisfies IShoppingSaleReview.ICreate,\n      },\n    );\n  typia.assert(review);\n\n  // 10. Customer modifies the review post\n  const snapshot: IShoppingSaleReview.ISnapshot = \n    await api.functional.shoppings.customers.sales.reviews.update(\n      connection,\n      {\n        saleId: sale.id,\n        id: review.id,\n        body: {\n          title: \"Some new title\",\n          body: \"Some new content body\",\n        } satisfies IShoppingSaleReview.IUpdate,\n      },\n    );\n  typia.assert(snapshot);\n\n  // 11. Re-view the review post to confirm modifications\n  const read: IShoppingSaleReview = \n    await api.functional.shoppings.customers.sales.reviews.at(\n      connection,\n      {\n        saleId: sale.id,\n        id: review.id,\n      },\n    );\n  typia.assert(read);\n  TestValidator.equals(\"snapshots\")(read.snapshots)([\n    ...review.snapshots,\n    snapshot,\n  ]);\n}\n```\n\n### 5.1. Implementation Example Commentary\n\n**1. Import Statements**: Explicitly import all necessary types and utilities, accurately referencing package paths in `@ORGANIZATION/PROJECT-api` format and type definitions under `lib/structures/`. Follow the standardized import guidelines with proper grouping and alphabetical ordering.\n\n**2. Comment Structure**: JSDoc comments at the top of functions explain the background and necessity of entire scenarios, specifying detailed 11-step processes with numbers.\n\n**3. Function Name**: `test_api_shopping_sale_review_update` follows naming conventions expressing domain (shopping), entity (sale), function (review), and action (update) in order.\n\n**4. Variable Type Declaration**: Declare each API call result with clear types (`IShoppingSeller`, `IShoppingSale`, etc.) to ensure type safety.\n\n**5. SDK Function Calls**: Use exact namespace paths like `api.functional.shoppings.sellers.authenticate.join` and structure parameters according to SDK definitions.\n\n**6. satisfies Usage**: Use `satisfies` keyword in request body to enhance type safety (`satisfies IShoppingSeller.IJoin`, etc.).\n\n**7. Type Validation**: Apply `typia.assert()` to all API responses to ensure runtime type safety.\n\n**8. Account Switching**: Call login functions at appropriate times for role switching between sellers and customers.\n\n**9. Data Validation**: Use `TestValidator.equals()` to validate ID matching, array state changes, etc.\n\n**10. Complex Data Structures**: Appropriately structure complex nested objects like delivery information and shopping cart products to reflect actual business logic.\n\n## 6. Error Prevention Guidelines\n\n### 6.1. Common Mistake Prevention\n- **Typo Prevention**: Verify accuracy of SDK function paths, type names, property names\n- **Type Consistency**: Ensure consistency between variable type declarations and actual usage\n- **Missing Required Validation**: Verify application of `typia.assert()`\n- **Missing Imports**: Verify import of all necessary types and utilities\n- **Code Style**: Maintain consistent indentation, naming conventions, comment style\n\n### 6.2. Business Logic Validation\n- Adhere to logical order of scenarios\n- Verify fulfillment of essential prerequisites\n- Consider data dependency relationships\n- **State Transition**: Verify proper data state changes in each step\n- **Permission Check**: Verify only appropriate APIs are called for each user role\n\n### 6.3. Type Safety Assurance\n- Perform appropriate type validation on all API responses\n- Use `satisfies` keyword in request body\n- Verify consistency between DTO interfaces and actual data structures\n- **Compile Time**: Utilize TypeScript compiler's type checking\n- **Runtime**: Actual data validation through `typia.assert`\n\n## 7. Quality Standards\n\n### 7.1. Completeness\n- All scenario steps implemented without omission\n- Appropriate validation performed for each step\n- Consideration of exceptional situations included\n- **Test Coverage**: Include all major API endpoints\n- **Edge Cases**: Handle possible error situations\n\n### 7.2. Readability\n- Use clear and meaningful variable names\n- Include appropriate comments and explanations\n- Maintain logical code structure and consistent indentation\n- **Step-by-step Comments**: Clearly separate each business step\n- **Code Formatting**: Maintain consistent style and readability\n\n### 7.3. Maintainability\n- Utilize reusable patterns\n- Minimize hardcoded values\n- Design with extensible structure\n- **Modularization**: Implement repetitive logic with clear patterns\n- **Extensibility**: Structure that allows easy addition of new test cases\n\n## 8. Error Scenario Testing (Appendix)\n\n### 8.1. Purpose and Importance of Error Testing\nE2E testing must verify that systems operate correctly not only in normal business flows but also in expected error situations. It's important to confirm that appropriate HTTP status codes and error messages are returned in situations like incorrect input, unauthorized access, requests for non-existent resources.\n\n### 8.2. Error Validation Function Usage\n- **TestValidator.error()**: For general error situations where HTTP status code cannot be determined with certainty\n- **TestValidator.httpError()**: When specific HTTP status code can be determined with confidence\n- **Format**: `TestValidator.httpError(\"description\")(statusCode)(() => APICall)`\n\n### 8.3. Error Test Writing Principles\n- **Clear Failure Conditions**: Clearly set conditions that should intentionally fail\n- **Appropriate Test Data**: Simulate realistic error situations like non-existent emails, incorrect passwords\n- **Concise Structure**: Unlike normal flows, compose error tests with minimal steps\n- **Function Naming Convention**: `test_api_{domain}_{action}_failure` or `test_api_{domain}_{action}_{specific_error}`\n- **CRITICAL**: Never use `// @ts-expect-error` comments when testing error cases. These functions test **runtime errors**, not compilation errors. The TypeScript code should compile successfully while the API calls are expected to fail at runtime.\n\n### 8.4. Error Test Example\n\n```typescript\nimport { TestValidator } from \"@nestia/e2e\";\n\nimport api from \"@ORGANIZATION/PROJECT-api\";\nimport { IShoppingCustomer } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingCustomer\";\n\n/**\n * Validate customer login failure.\n * \n * Verify that appropriate error response is returned when attempting \n * to login with a non-existent email address.\n */\nexport async function test_api_customer_authenticate_login_failure(\n  connection: api.IConnection,\n): Promise<void> {\n  await TestValidator.httpError(\"login failure\")(403)(() =>\n    api.functional.shoppings.customers.authenticate.login(\n      connection,\n      {\n        body: {\n          email: \"never-existing-email@sadfasdfasdf.com\",\n          password: \"1234\",\n        } satisfies IShoppingCustomer.ILogin,\n      },\n    ),\n  );\n}\n```\n\n### 8.5. Common Error Test Scenarios\n- **Authentication Failure**: Incorrect login information, expired tokens\n- **Permission Error**: Requests for resources without access rights\n- **Resource Not Found**: Attempts to query with non-existent IDs\n- **Validation Failure**: Input of incorrectly formatted data\n- **Duplicate Data**: Signup attempts with already existing emails\n\n### 8.6. Precautions When Writing Error Tests\n- Write error tests as separate independent functions\n- Do not mix with normal flow tests\n- Accurately specify expected HTTP status codes\n- Focus on status codes rather than error message content\n- **IMPORTANT**: Never add `// @ts-expect-error` comments - error validation functions handle runtime errors while maintaining TypeScript type safety\n\n## 9. Final Checklist\n\nE2E test function writing completion requires verification of the following items:\n\n### 9.1. Essential Element Verification\n- [ ] Are all scenario steps implemented in order?\n- [ ] Are complete JSDoc-style comments written?\n- [ ] Does the function name follow naming conventions (`test_api_{domain}_{action}_{scenario}`)?\n- [ ] Are SDK used for all API calls?\n- [ ] Is the `satisfies` keyword used in request body?\n- [ ] Is `typia.assert` applied where necessary?\n- [ ] Are all necessary types imported with correct paths?\n- [ ] Do import statements follow the standardized guidelines (typia, API SDK, DTO types, TestValidator)?\n- [ ] Are error test cases written without `// @ts-expect-error` comments?\n\n### 9.2. Quality Element Verification\n- [ ] Are variable names meaningful and consistent?\n- [ ] Are account switches performed at appropriate times?\n- [ ] Is data validation performed correctly?\n- [ ] Is code structure logical with good readability?\n- [ ] Are error scenarios handled appropriately when needed without TypeScript error suppression comments?\n- [ ] Is business logic completeness guaranteed?\n- [ ] Are imports organized properly with alphabetical ordering within groups?\n\nPlease adhere to all these principles and guidelines to write complete and accurate E2E test functions. Your mission is not simply to write code, but to build a robust test system that perfectly reproduces and validates actual business scenarios." /* AutoBeSystemPromptConstant.TEST_WRITE */,
+        },
+        {
+            id: (0, uuid_1.v4)(),
+            created_at: new Date().toISOString(),
+            type: "assistantMessage",
+            text: [
+                "Here is the list of input material composition.",
+                "",
+                "Make e2e test functions based on the following information.",
+                "",
+                "## Secnario Plan",
+                "```json",
+                JSON.stringify(props.scenario),
+                "```",
+                "",
+                "## DTO Definitions",
+                "```json",
+                JSON.stringify(props.artifacts.dto),
+                "```",
+                "",
+                "## API (SDK) Functions",
+                "```json",
+                JSON.stringify(props.artifacts.sdk),
+                "```",
+                "",
+                "## E2E Mockup Functions",
+                "```json",
+                JSON.stringify(props.artifacts.e2e),
+                "```",
+                "",
+            ].join("\n"),
+        },
+    ];
+};
+exports.transformTestWriteHistories = transformTestWriteHistories;
+//# sourceMappingURL=transformTestWriteHistories.js.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"transformTestWriteHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/test/transformTestWriteHistories.ts"],"names":[],"mappings":";;;AAEA,+BAA0B;AAKnB,MAAM,2BAA2B,GAAG,CAAC,KAG3C,EAEC,EAAE;IACF,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,4hrCAAuC;SAC5C;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE;gBACJ,iDAAiD;gBACjD,EAAE;gBACF,6DAA6D;gBAC7D,EAAE;gBACF,kBAAkB;gBAClB,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,QAAQ,CAAC;gBAC9B,KAAK;gBACL,EAAE;gBACF,oBAAoB;gBACpB,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,SAAS,CAAC,GAAG,CAAC;gBACnC,KAAK;gBACL,EAAE;gBACF,wBAAwB;gBACxB,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,SAAS,CAAC,GAAG,CAAC;gBACnC,KAAK;gBACL,EAAE;gBACF,yBAAyB;gBACzB,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,SAAS,CAAC,GAAG,CAAC;gBACnC,KAAK;gBACL,EAAE;aACH,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AA7CW,QAAA,2BAA2B,+BA6CtC"}

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>;