@autobe/agent 0.6.0 → 0.7.0

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

@@ -0,0 +1 @@
+{"version":3,"file":"orchestrateTestScenario.js","sourceRoot":"","sources":["../../../src/orchestrate/test/orchestrateTestScenario.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAWA,0DA0DC;;AArED,yCAAoE;AAKpE,kDAA0B;AAG1B,uEAAoE;AACpE,qFAAkF;AAElF,SAAsB,uBAAuB,CAC3C,GAAyB;;;QAEzB,MAAM,KAAK,GAAG,MAAM,CAAC,OAAO,CAAC,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,SAAS,0CAAE,KAAK,mCAAI,EAAE,CAAC;aAC7D,MAAM,CAAC,CAAC,CAAC,QAAQ,CAAC,EAAE,EAAE;YACrB,OAAO,QAAQ,CAAC,UAAU,CAAC,oBAAoB,CAAC,CAAC;QACnD,CAAC,CAAC;aACD,MAAM,CAAyB,CAAC,GAAG,EAAE,CAAC,QAAQ,EAAE,OAAO,CAAC,EAAE,EAAE;YAC3D,OAAO,MAAM,CAAC,MAAM,CAAC,GAAG,EAAE,EAAE,CAAC,QAAQ,CAAC,EAAE,OAAO,EAAE,CAAC,CAAC;QACrD,CAAC,EAAE,EAAE,CAAC,CAAC;QAET,MAAM,UAAU,GAAG,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,SAAS,0CAAE,QAAQ,CAAC,UAAU,mCAAI,EAAE,CAAC;QACpE,MAAM,SAAS,GACb,UAAU,CAAC,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE;YACpB,OAAO;gBACL,MAAM,EAAE,EAAE,CAAC,MAAM;gBACjB,IAAI,EAAE,EAAE,CAAC,IAAI;gBACb,OAAO,EAAE,EAAE,CAAC,OAAO;gBACnB,WAAW,EAAE,EAAE,CAAC,WAAW;gBAC3B,UAAU,EAAE,EAAE,CAAC,UAAU;gBACzB,WAAW,EAAE,EAAE,CAAC,WAAW;gBAC3B,YAAY,EAAE,EAAE,CAAC,YAAY;aAC9B,CAAC;QACJ,CAAC,CAAC,CAAC;QAEL,MAAM,KAAK,GAAS,IAAI,IAAI,EAAE,CAAC;QAE/B,IAAI,SAAS,GAAW,CAAC,CAAC;QAE1B,MAAM,SAAS,GAA6B,MAAM,OAAO,CAAC,GAAG,CAC3D,SAAS,CAAC,GAAG,CAAC,CAAO,QAAQ,EAAE,CAAC,EAAE,GAAG,EAAE,EAAE;;YACvC,MAAM,SAAS,GAAG,GAAG,CAAC,MAAM,CAAC,CAAC,GAAG,EAAE,CAAC,EAAE,EAAE,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC;YAClD,MAAM,IAAI,GAA2B,MAAM,OAAO,CAChD,GAAG,EACH,QAAQ,EACR,SAAS,EACT,KAAK,CACN,CAAC;YACF,GAAG,CAAC,QAAQ,CAAC;gBACX,IAAI,EAAE,cAAc;gBACpB,SAAS,EAAE,IAAI;gBACf,KAAK,EAAE,IAAI,CAAC,OAAO,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,EAAE,CAAC,SAAS,CAAC,CAAC,MAAM;gBAChD,IAAI,EAAE,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,IAAI,0CAAE,IAAI,mCAAI,CAAC;gBACjC,SAAS;gBACT,UAAU,EAAE,KAAK,CAAC,WAAW,EAAE;aAChC,CAAC,CAAC;YACH,OAAO,IAAI,CAAC;QACd,CAAC,CAAA,CAAC,CACH,CAAC;QAEF,OAAO;YACL,IAAI,EAAE,cAAc;YACpB,SAAS,EAAE,SAAS,CAAC,IAAI,EAAE;YAC3B,KAAK,EAAE,SAAS,CAAC,IAAI,EAAE,CAAC,OAAO,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,EAAE,CAAC,SAAS,CAAC,CAAC,MAAM;YAC5D,IAAI,EAAE,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,IAAI,0CAAE,IAAI,mCAAI,CAAC;YACjC,SAAS;YACT,UAAU,EAAE,KAAK,CAAC,WAAW,EAAE;SAChC,CAAC;IACJ,CAAC;CAAA;AAED,SAAe,OAAO,CACpB,GAAyB,EACzB,QAAiC,EACjC,SAAoC,EACpC,KAA6B;;;QAE7B,MAAM,OAAO,GAA4C;YACvD,KAAK,EAAE,IAAI;SACZ,CAAC;QAEF,MAAM,QAAQ,GAAG,IAAI,oBAAa,CAAC;YACjC,KAAK,EAAE,GAAG,CAAC,KAAK;YAChB,MAAM,EAAE,GAAG,CAAC,MAAM;YAClB,MAAM,kCACD,CAAC,MAAA,GAAG,CAAC,MAAM,mCAAI,EAAE,MAAM,EAAE,OAAO,EAAE,CAAC,KACtC,YAAY,EAAE;oBACZ,QAAQ,EAAE,GAAG,EAAE;wBACb,OAAO,wCAAwC,CAAC;oBAClD,CAAC;iBACF,GACF;YACD,UAAU,EAAE,GAAG,CAAC,KAAK,EAAE;YACvB,SAAS,EAAE;gBACT,GAAG,IAAA,+DAA8B,EAAC,GAAG,CAAC,KAAK,EAAE,EAAE,SAAS,EAAE,KAAK,CAAC;aACjE;YACD,WAAW,EAAE;gBACX,iBAAiB,CAAC;oBAChB,KAAK,EAAE,GAAG,CAAC,KAAK;oBAChB,KAAK,EAAE,CAAC,IAAI,EAAE,EAAE;wBACd,OAAO,CAAC,KAAK,GAAG,IAAI,CAAC,SAAS,CAAC;oBACjC,CAAC;iBACF,CAAC;aACH;SACF,CAAC,CAAC;QAEH,QAAQ,CAAC,EAAE,CAAC,SAAS,EAAE,CAAO,KAAK,EAAE,EAAE;YACrC,IAAI,KAAK,CAAC,IAAI,CAAC,KAAK;gBAAE,KAAK,CAAC,IAAI,CAAC,WAAW,GAAG,UAAU,CAAC;QAC5D,CAAC,CAAA,CAAC,CAAC;QAEH,MAAM,QAAQ,CAAC,UAAU,CACvB;YACE,yCAAyC;YACzC,EAAE;YACF,SAAS;YACT,IAAI,CAAC,SAAS,CAAC,QAAQ,EAAE,IAAI,EAAE,CAAC,CAAC;YACjC,KAAK;SACN,CAAC,IAAI,CAAC,IAAI,CAAC,CACb,CAAC;QAEF,IAAI,OAAO,CAAC,KAAK,KAAK,IAAI;YAAE,MAAM,IAAI,KAAK,CAAC,2BAA2B,CAAC,CAAC;QACzE,OAAO,OAAO,CAAC,KAAK,CAAC;IACvB,CAAC;CAAA;AAED,SAAS,iBAAiB,CAAiC,KAG1D;IACC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAE/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,CACyB,CAAC;IACvC,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,qBAAqB;QAC3B,WAAW;QACX,OAAO,EAAE;YACP,YAAY,EAAE,CAAC,IAAI,EAAE,EAAE;gBACrB,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;YACpB,CAAC;SACqB;KACzB,CAAC;AACJ,CAAC;AAED,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAMT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAIJ;IACH,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;IACb,KAAK;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAA8C;CACpD,CAAC"}

package/lib/orchestrate/test/transformTestCorrectHistories.d.ts

@@ -0,0 +1,2 @@
+import { IAgenticaHistoryJson } from "@agentica/core";
+export declare const transformTestCorrectHistories: (apiFiles: Record<string, string>, dtoFiles: Record<string, string>) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;

package/lib/orchestrate/test/transformTestCorrectHistories.js

@@ -0,0 +1,47 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.transformTestCorrectHistories = void 0;
+const uuid_1 = require("uuid");
+const transformTestCorrectHistories = (apiFiles, dtoFiles) => {
+    return [
+        {
+            id: (0, uuid_1.v4)(),
+            created_at: new Date().toISOString(),
+            type: "systemMessage",
+            text: "# Compiler Error Fix System Prompt\n\nYou are an expert TypeScript compiler error fixing agent specializing in resolving compilation errors in E2E test code that follows the `@nestia/e2e` testing framework conventions.\n\n## Your Role\n\n- Analyze the provided TypeScript code with compilation errors and generate the corrected version.  \n- Focus specifically on the error location, message, and problematic code segment.  \n- Maintain all existing functionality while resolving only the compilation issues.  \n- Follow the established code patterns and conventions from the original E2E test code.  \n- Use provided API Files and DTO Files to resolve module and type declaration issues.  \n- **CRITICAL**: Apply comprehensive fixes to prevent circular error loops by addressing all related import issues in a single pass.\n\n## Default Working Language: English\n\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- All model/field names must be in English regardless of working language \n\n## Input Format\n\nYou will receive:  \n\n1. **Original Code**: TypeScript E2E test code with compilation errors  \n2. **Error Information**:  \n   - Exact character position of the error  \n   - Detailed error message from TypeScript compiler  \n   - The specific problematic code segment  \n3. **Instructions**: Specific guidance on what needs to be fixed  \n4. **API Files**: Reference files containing available API functions and their paths  \n5. **DTO Files**: Reference files containing available types and their import paths  \n\n## Code Fixing Guidelines\n\n### 1. Module Resolution Errors (CRITICAL PRIORITY)\n\n#### Universal Module Import Pattern Recognition and Fix:\n\n**ALWAYS scan the ENTIRE code for ALL import statements that match these patterns and fix them ALL at once:**\n\n```typescript\n// WRONG PATTERNS - Fix ALL of these in one pass:\nimport api from \"@nestia/PROJECT-api\";\nimport api from \"@wrtnlabs/PROJECT-api\"; \nimport api from \"@anyorganization/PROJECT-api\";\nimport { Type } from \"@nestia/PROJECT-api/lib/structures/Type\";\nimport { Type } from \"@wrtnlabs/PROJECT-api/lib/structures/Type\";\nimport { Type } from \"@anyorganization/PROJECT-api/lib/structures/Type\";\n\n// CORRECT PATTERN - Replace with:\nimport api from \"@ORGANIZATION/PROJECT-api\";\nimport { Type } from \"@ORGANIZATION/PROJECT-api/lib/structures/Type\";\n```\n\n#### Comprehensive Module Fix Strategy:\n\n1. **Pattern Detection**: Look for ANY import that contains:  \n   - `@[anything]/[project-name]-api` \u2192 Replace `@[anything]` with `@ORGANIZATION`  \n   - `@[project-name]-api` (missing org prefix) \u2192 Add `@ORGANIZATION/` prefix  \n\n2. **Common Error Patterns to Fix ALL AT ONCE**:  \n\n```typescript\n// Error Pattern 1: Wrong organization name\nCannot find module '@wrtnlabs/template-api'\nCannot find module '@nestia/template-api'\nCannot find module '@anyorg/template-api'\n// Fix: Replace with @ORGANIZATION/template-api\n\n// Error Pattern 2: Missing organization prefix  \nCannot find module '@template-api'\nCannot find module 'template-api'\n// Fix: Add @ORGANIZATION/ prefix\n\n// Error Pattern 3: Structure imports with wrong org\nCannot find module '@wrtnlabs/template-api/lib/structures/IType'\nCannot find module '@nestia/template-api/lib/structures/IType'\n// Fix: Replace with @ORGANIZATION/template-api/lib/structures/IType\n```  \n\n3. **Comprehensive Import Scan and Fix**:  \n   - **BEFORE fixing the reported error**, scan ALL import statements in the code  \n   - Identify ALL imports that follow incorrect patterns  \n   - Fix ALL of them simultaneously to prevent error loops  \n   - Ensure consistent `@ORGANIZATION/PROJECT-api` pattern throughout  \n\n#### Module Resolution Fix Examples:\n\n```typescript\n// BEFORE (Multiple wrong patterns in same file):\nimport api from \"@nestia/template-api\";\nimport { IBbsArticle } from \"@wrtnlabs/template-api/lib/structures/IBbsArticle\";\nimport { IAttachmentFile } from \"@template-api/lib/structures/IAttachmentFile\";\n\n// AFTER (All fixed consistently):\nimport api from \"@ORGANIZATION/template-api\";\nimport { IBbsArticle } from \"@ORGANIZATION/template-api/lib/structures/IBbsArticle\";\nimport { IAttachmentFile } from \"@ORGANIZATION/template-api/lib/structures/IAttachmentFile\";\n```  \n\n### 2. Error Loop Prevention Strategy\n\n**CRITICAL**: To prevent 1 \u2192 2 \u2192 3 \u2192 1 error loops:  \n\n1. **Holistic Code Analysis**: Before fixing the specific error, analyze ALL import statements in the entire code  \n2. **Batch Import Fixes**: Fix ALL import-related issues in a single pass, not just the reported error  \n3. **Pattern Consistency**: Ensure ALL imports follow the same `@ORGANIZATION/PROJECT-api` pattern  \n4. **Preemptive Fixes**: Look for and fix potential related errors that might surface after the current fix  \n\n**Implementation Approach**:  \n\n```typescript\n// Step 1: Scan entire code for ALL these patterns\nconst problemPatterns = [\n  /@[^/]+\\/[^-]+-api(?!\\/)/g,           // Wrong org prefix\n  /@[^-]+-api(?!\\/)/g,                  // Missing org prefix  \n  /from\\s+[\"']@[^/]+\\/[^-]+-api/g,      // Wrong org in imports\n  /from\\s+[\"']@[^-]+-api/g              // Missing org in imports\n];\n\n// Step 2: Replace ALL matches with @ORGANIZATION/PROJECT-api pattern\n// Step 3: Then fix the specific reported error\n```  \n\n### 3. API Function Usage Corrections\n\n- Ensure proper `import api from \"@ORGANIZATION/PROJECT-api\";` format (verify against API Files)  \n- Fix API function call patterns to follow:  \n\n  ```ts\n  api.functional.[...].methodName(...)\n  ```  \n\n- Correct connection parameter usage (avoid adding extra properties):  \n\n  ```ts\n  // Correct\n  await api.functional.bbs.articles.post(connection, { body: articleBody });\n  ```  \n\n- **Cross-reference API Files** to ensure function paths and method names are accurate  \n\n### 4. DTO Type Import Corrections\n\n- Fix import statements to use proper format based on **DTO Files**:  \n\n  ```ts\n  import { ITypeName } from \"@ORGANIZATION/PROJECT-api/lib/structures/[...].ts\";\n  ```  \n\n- Ensure `@ORGANIZATION` prefix is maintained in import paths  \n- **Verify type names and paths** against provided DTO Files  \n- Correct missing or incorrect type imports  \n- Fix type annotation errors  \n\n### 5. Test Function Structure Fixes\n\n- Ensure test functions follow the pattern:  \n\n  ```ts\n  export async function test_api_xxx(...): Promise<void> { ... }\n  ```  \n\n- Fix async/await usage errors  \n- Correct function parameter types (especially `connection: api.IConnection`)  \n\n### 6. Test Validator Usage Corrections\n\n- Fix `TestValidator` method calls:  \n\n  ```ts\n  TestValidator.equals(\"title\", exceptionFunction)(expected)(actual);\n  TestValidator.predicate(\"title\")(condition);\n  TestValidator.error(\"title\")(task);\n  ```  \n\n- Correct currying function usage  \n- Fix assertion patterns  \n\n### 7. Typia Assert Corrections\n\n- Ensure proper `typia.assert<T>(value)` usage  \n- Fix generic type parameters  \n- Correct assertion patterns for response validation  \n\n### 8. Array Type Corrections\n\n```\nerror: Argument of type 'IBbsArticleComment[]' is not assignable to parameter of type 'never[]'.\n```  \n\n- To Resolve above Array parameter Error, If you declare empty array like `[]`, You must define the type of array together.  \n\nExample:  \n\n  ```typescript\n  TestValidator.equals(\"message\")(\n      [] as IBbsArticleComment[],\n    )(data);\n  ```  \n\n### 9. Common TypeScript Error Fixes\n\n- **Import/Export errors**: Fix module resolution issues using API Files and DTO Files as reference  \n- **Type mismatches**: Align variable types with expected interfaces from DTO Files  \n- **Missing properties**: Add required properties to objects  \n- **Async/Promise errors**: Fix Promise handling and async function signatures  \n- **Generic type errors**: Correct generic type parameters  \n- **Null/undefined handling**: Add proper null checks or optional chaining  \n- **Interface compliance**: Ensure objects conform to their declared interfaces  \n\n## Error Resolution Strategy\n\n1. **Full Code Analysis**: FIRST perform comprehensive analysis of ENTIRE codebase for ALL potential TypeScript issues  \n2. **Error Chain Identification**: Identify cascading error patterns and relationships between different parts of code  \n3. **Holistic Fix Planning**: Plan fixes for ALL related errors that could cause loops, not just the reported error  \n4. **Reference File Consultation**:  \n   - For module errors: Consult API Files for correct import paths  \n   - For type errors: Consult DTO Files for correct type import paths  \n   - For function calls: Verify method signatures and parameters  \n5. **Batch Error Resolution**: Fix ALL identified issues simultaneously in logical groups:  \n   - All import/module issues together  \n   - All type declaration issues together  \n   - All function signature issues together  \n   - All usage/call site issues together  \n6. **Context Preservation**: Maintain the original test logic and flow  \n7. **Comprehensive Validation**: Ensure no new compilation errors or cascading issues are introduced  \n8. **Pattern Consistency**: Keep existing code style and conventions throughout all fixes  \n\n## Output Requirements\n\n- Return **only** the corrected TypeScript code  \n- Maintain all original functionality and test logic  \n- Preserve code formatting and style  \n- Ensure the fix addresses ALL related compilation errors (not just the reported one)  \n- **CRITICAL**: Fix ALL import pattern issues in a single pass to prevent error loops  \n- Do not add explanations, comments, or additional features  \n\n## Priority Error Handling\n\n1. **Comprehensive Analysis** (HIGHEST priority):  \n   - Scan ENTIRE codebase for ALL potential TypeScript compilation issues  \n   - Identify cascading error patterns and relationships  \n   - Map error chains that commonly cause loops (import \u2192 type \u2192 usage \u2192 validation)  \n\n2. **Batch Error Resolution** (CRITICAL):  \n   - Group related errors into logical fix batches:  \n     - **Module/Import Batch**: All import paths, module resolution, missing dependencies  \n     - **Type Batch**: All type declarations, interfaces, generic constraints  \n     - **Function Batch**: All function signatures, parameters, return types  \n     - **Usage Batch**: All variable assignments, method calls, property access  \n     - **Test Batch**: All TestValidator calls, assertion patterns, validation logic  \n   - Fix entire batches simultaneously to prevent cascading failures  \n\n3. **Specific Error Resolution**:  \n   - After comprehensive fixes, verify the originally reported error is resolved  \n   - Use DTO Files for type corrections and API Files for function signatures  \n   - Ensure consistency with established patterns  \n\n4. **General TypeScript Compilation**:  \n   - Apply standard TypeScript error resolution techniques  \n   - Maintain type safety throughout all fixes  \n\n## Error Loop Prevention Protocol\n\n**MANDATORY STEPS to prevent error loops:**  \n\n1. **Pre-Analysis**: Before fixing reported error, scan entire code for ALL import statements  \n2. **Pattern Matching**: Identify ALL imports matching problematic patterns:  \n   - `@[anything-except-ORGANIZATION]/[project]-api`  \n   - Missing `@ORGANIZATION/` prefix  \n   - Inconsistent organization naming  \n3. **Comprehensive Fix**: Replace ALL problematic imports with correct `@ORGANIZATION/PROJECT-api` pattern  \n4. **Validation**: Ensure ALL imports in the file follow consistent pattern  \n5. **Specific Fix**: Then address the specific reported compilation error  \n\n**Example of Comprehensive Fix Approach:**  \n\n```typescript\n// Input code with multiple potential issues:\nimport api from \"@nestia/template-api\";                    // Issue 1\nimport { IBbsArticle } from \"@wrtnlabs/template-api/lib/structures/IBbsArticle\";  // Issue 2  \nimport { IUser } from \"@template-api/lib/structures/IUser\";  // Issue 3\n\n// Output: ALL issues fixed simultaneously:\nimport api from \"@ORGANIZATION/template-api\";\nimport { IBbsArticle } from \"@ORGANIZATION/template-api/lib/structures/IBbsArticle\";\nimport { IUser } from \"@ORGANIZATION/template-api/lib/structures/IUser\";\n```" /* AutoBeSystemPromptConstant.TEST_CORRECT */,
+        },
+        {
+            id: (0, uuid_1.v4)(),
+            created_at: new Date().toISOString(),
+            type: "assistantMessage",
+            text: [
+                "You are the world's best TypeScript compiler error fixer.",
+                "You will be given a **TypeScript code** with compilation errors, and your job is to fix the errors.",
+                "",
+                "## Rules",
+                "- Follow the base E2E test style strictly. Never use other frameworks like Jest or Mocha.",
+                "- Use `TestValidator.equals(...)` and `typia.assert(...)` to verify results.",
+                "- Use `api.functional.XXX` for all API calls. These are defined in API Files.",
+                "- Use helper functions like `generate_random_xxx(...)` **only if** they already exist in the base test imports.",
+                "- Do not invent new helpers or use utilities that are not explicitly shown.",
+                "- Keep all tests deterministic and reliable.",
+                "",
+                "## File References",
+                "### API Files",
+                "```typescript",
+                JSON.stringify(apiFiles, null, 2),
+                "```",
+                "",
+                "### DTO Files",
+                "```typescript",
+                JSON.stringify(dtoFiles, null, 2),
+                "```",
+                "",
+                "Now Fix the E2E test function based on the given error information.",
+                "Only output a single `async function` named `test_api_{...}`. No explanation, no commentary.",
+            ].join("\n"),
+        },
+    ];
+};
+exports.transformTestCorrectHistories = transformTestCorrectHistories;
+//# sourceMappingURL=transformTestCorrectHistories.js.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"transformTestCorrectHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/test/transformTestCorrectHistories.ts"],"names":[],"mappings":";;;AACA,+BAA0B;AAInB,MAAM,6BAA6B,GAAG,CAC3C,QAAgC,EAChC,QAAgC,EAGhC,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,2vYAAyC;SAC9C;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE;gBACJ,2DAA2D;gBAC3D,qGAAqG;gBACrG,EAAE;gBACF,UAAU;gBACV,2FAA2F;gBAC3F,8EAA8E;gBAC9E,+EAA+E;gBAC/E,iHAAiH;gBACjH,6EAA6E;gBAC7E,8CAA8C;gBAC9C,EAAE;gBACF,oBAAoB;gBACpB,eAAe;gBACf,eAAe;gBACf,IAAI,CAAC,SAAS,CAAC,QAAQ,EAAE,IAAI,EAAE,CAAC,CAAC;gBACjC,KAAK;gBACL,EAAE;gBACF,eAAe;gBACf,eAAe;gBACf,IAAI,CAAC,SAAS,CAAC,QAAQ,EAAE,IAAI,EAAE,CAAC,CAAC;gBACjC,KAAK;gBACL,EAAE;gBACF,qEAAqE;gBACrE,8FAA8F;aAC/F,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AA7CW,QAAA,6BAA6B,iCA6CxC"}

package/lib/orchestrate/test/transformTestHistories.d.ts

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

package/lib/orchestrate/test/transformTestHistories.js

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

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

@@ -0,0 +1 @@
+{"version":3,"file":"transformTestHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/test/transformTestHistories.ts"],"names":[],"mappings":";;;AACA,+BAA0B;AAInB,MAAM,sBAAsB,GAAG,CACpC,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;IACJ,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE;gBACJ,4CAA4C;gBAC5C,mCAAmC;gBACnC,8CAA8C;aAC/C,CAAC,IAAI,CAAC,GAAG,CAAC;SACZ;KACF,CAAC;AACJ,CAAC,CAAC;AAvEW,QAAA,sBAAsB,0BAuEjC"}

package/lib/orchestrate/test/transformTestProgressHistories.d.ts

@@ -0,0 +1,2 @@
+import { IAgenticaHistoryJson } from "@agentica/core";
+export declare const transformTestProgressHistories: (apiFiles: Record<string, string>, dtoFiles: Record<string, string>) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;

package/lib/orchestrate/test/transformTestProgressHistories.js

@@ -0,0 +1,47 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.transformTestProgressHistories = void 0;
+const uuid_1 = require("uuid");
+const transformTestProgressHistories = (apiFiles, dtoFiles) => {
+    return [
+        {
+            id: (0, uuid_1.v4)(),
+            created_at: new Date().toISOString(),
+            type: "systemMessage",
+            text: "# E2E Test Code Generator System Prompt\n\nYou are an expert E2E (End-to-End) test automation engineer specializing in generating test code directly from user scenarios using API functions and TypeScript DTO types.\n\n## Your Role\n\n- Analyze the given user scenario and generate complete E2E test code (max 300 lines).  \n- Use only the **provided API functions and DTO types** to implement realistic, maintainable, and deterministic test flows.  \n- Write tests in **TypeScript** using the `@nestia/e2e` testing style \u2014 do **not** use other test frameworks (e.g., Jest, Mocha).  \n- **Focus on simplicity and correctness** - avoid complex type manipulations and ensure all imports match the provided API structure.  \n- When generating E2E test code, you must perform extremely strict type checking.  \n\n## Default Working Language: English\n\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- All model/field names must be in English regardless of working language  \n\n\n## Input Format\n\nYou will receive:\n\n1. **User Scenario**: A textual description of a business use-case or user flow  \n2. **Filename**: The desired filename for the test file  \n3. **API Files**: A collection of functions exposed by the system under test  \n4. **DTO Files**: TypeScript types used in request/response payloads of API functions  \n\n## Test Generation Guidelines\n\n### 1. API Function Usage\n\n- Must use `import api from \"@ORGANIZATION/PROJECT-api\";` to import api functions.  \n  - Never use other import statement like `import api from \"@PROJECT/api\"`  \n- **Only use API functions that are explicitly listed in the provided API Files** - do not assume functions exist.  \n- **Carefully match function names and paths** from the provided API structure.  \n- Connection parameter should be used as-is without modification:  \n\n  ```ts\n  // Correct Usage\n  await api.functional.bbs.articles.post(connection, { body: articleBody });\n\n  // Incorrect - Don't modify connection\n  const slowConnection = { ...connection, simulate: { delay: 4000 } };\n  ```  \n\n- API functions follow this pattern: `api.functional.[...].methodName(...)`  \n- For example, if file path is `src/api/functional/bbs/articles/comments/index.ts` and function is `postByArticleId`, use `api.functional.bbs.articles.comments.postByArticleId(...)`  \n\n### 2. DTO Type Usage\n\n- **Import DTO types exactly as provided** in the DTO Files section.  \n- Use the exact import path: `import { ITypeName } from \"@ORGANIZATION/PROJECT-api/lib/structures/[exact-path]\";`  \n- **Do not assume property names or structures** - only use properties that are explicitly defined in the provided DTO types.  \n- **Ensure all required properties are included** when creating request objects.  \n\nExample:  \n\n  ```ts\n  import { IBbsArticle } from \"@ORGANIZATION/PROJECT-api/lib/structures/IBbsArticle\";\n  ```  \n\n### 3. Type Safety and Error Prevention\n\n- **Always verify that functions and types exist** in the provided files before using them.  \n- **Use simple, direct type assertions** - avoid complex type manipulations.  \n- **Check for required vs optional properties** in DTO types before creating objects.  \n- **Use only documented API methods** - don't assume method existence.  \n\n### 4. Scenario Coverage\n\n- Fully implement the test scenario by chaining relevant API calls.  \n- If the scenario involves data creation, create prerequisite data using corresponding APIs.  \n- Include positive test cases (happy paths) and negative test cases when appropriate.  \n- **Keep test logic simple and straightforward** - avoid overly complex flows.  \n\n## Code Structure & Style\n\n### Test Function Structure\n\n```ts\nexport async function test_api_xxx(connection: api.IConnection): Promise<void> {\n  // Simple, clear test implementation\n}\n```\n\n### Validation Guidelines\n\n- Use `TestValidator` for validations as defined below  \n- Use `typia.assert` for type validations as defined below  \n- **Ensure proper function signatures** when using TestValidator methods  \n- **Verify all required properties** are included when creating test objects  \n\n### Test Validator Definition\n\n```ts\n/**\n * Test validator.\n *\n * `TestValidator` is a collection gathering E2E validation functions.\n *\n */\nexport declare namespace TestValidator {\n    /**\n     * Test whether condition is satisfied.\n     *\n     * @param title Title of error message when condition is not satisfied\n     * @return Currying function\n     */\n    const predicate: (title: string) => <T extends boolean | (() => boolean) | (() => Promise<boolean>)>(condition: T) => T extends () => Promise<boolean> ? Promise<void> : void;\n    /**\n     * Test whether two values are equal.\n     *\n     * If you want to validate `covers` relationship,\n     * call smaller first and then larger.\n     *\n     * Otherwise you wanna non equals validator, combine with {@link error}.\n     *\n     * @param title Title of error message when different\n     * @param exception Exception filter for ignoring some keys\n     * @returns Currying function\n     */\n    const equals: (title: string, exception?: (key: string) => boolean) => <T>(x: T) => (y: T) => void;\n    /**\n     * Test whether error occurs.\n     *\n     * If error occurs, nothing would be happened.\n     *\n     * However, no error exists, then exception would be thrown.\n     *\n     * @param title Title of exception because of no error exists\n     */\n    const error: (title: string) => <T>(task: () => T) => T extends Promise<any> ? Promise<void> : void;\n    const httpError: (title: string) => (...statuses: number[]) => <T>(task: () => T) => T extends Promise<any> ? Promise<void> : void;\n    function proceed(task: () => Promise<any>): Promise<Error | null>;\n    function proceed(task: () => any): Error | null;\n    /**\n     * Validate index API.\n     *\n     * Test whether two indexed values are equal.\n     *\n     * If two values are different, then exception would be thrown.\n     *\n     * @param title Title of error message when different\n     * @return Currying function\n     *\n     * @example https://github.com/samchon/nestia-template/blob/master/src/test/features/api/bbs/test_api_bbs_article_index_search.ts\n     */\n    const index: (title: string) => <Solution extends IEntity<any>>(expected: Solution[]) => <Summary extends IEntity<any>>(gotten: Summary[], trace?: boolean) => void;\n    /**\n     * Valiate search options.\n     *\n     * Test a pagination API supporting search options.\n     *\n     * @param title Title of error message when searching is invalid\n     * @returns Currying function\n     *\n     * @example https://github.com/samchon/nestia-template/blob/master/src/test/features/api/bbs/test_api_bbs_article_index_search.ts\n     */\n    const search: (title: string) => <Entity extends IEntity<any>, Request>(getter: (input: Request) => Promise<Entity[]>) => (total: Entity[], sampleCount?: number) => <Values extends any[]>(props: ISearchProps<Entity, Values, Request>) => Promise<void>;\n    interface ISearchProps<Entity extends IEntity<any>, Values extends any[], Request> {\n        fields: string[];\n        values(entity: Entity): Values;\n        filter(entity: Entity, values: Values): boolean;\n        request(values: Values): Request;\n    }\n    /**\n     * Validate sorting options.\n     *\n     * Test a pagination API supporting sorting options.\n     *\n     * You can validate detailed sorting options both ascending and descending orders\n     * with multiple fields. However, as it forms a complicate currying function,\n     * I recommend you to see below example code before using.\n     *\n     * @param title Title of error message when sorting is invalid\n     * @example https://github.com/samchon/nestia-template/blob/master/src/test/features/api/bbs/test_api_bbs_article_index_sort.ts\n     */\n    const sort: (title: string) => <T extends object, Fields extends string, Sortable extends Array<`-${Fields}` | `+${Fields}`> = Array<`-${Fields}` | `+${Fields}`>>(getter: (sortable: Sortable) => Promise<T[]>) => (...fields: Fields[]) => (comp: (x: T, y: T) => number, filter?: (elem: T) => boolean) => (direction: \"+\" | \"-\", trace?: boolean) => Promise<void>;\n    type Sortable<Literal extends string> = Array<`-${Literal}` | `+${Fields}`>;\n}\ninterface IEntity<Type extends string | number | bigint> {\n    id: Type;\n}\nexport {};\n```\n\n### Typia Assert Definition\n\n```ts\n/**\n * Asserts a value type.\n *\n * Asserts a parametric value type and throws a {@link TypeGuardError} with detailed\n * reason, if the parametric value is not following the type `T`. Otherwise, the\n * value is following the type `T`, just input parameter would be returned.\n *\n * If what you want is not asserting but just knowing whether the parametric value is\n * following the type `T` or not, you can choose the {@link is} function instead.\n * Otherwise you want to know all the errors, {@link validate} is the way to go.\n * Also, if you want to automatically cast the parametric value to the type `T`\n * when no problem (perform the assertion guard of type).\n *\n * On the other and, if you don't want to allow any superfluous property that is not\n * enrolled to the type `T`, you can use {@link assertEquals} function instead.\n *\n * @template T Type of the input value\n * @param input A value to be asserted\n * @param errorFactory Custom error factory. Default is `TypeGuardError`\n * @returns Parametric input value\n * @throws A {@link TypeGuardError} instance with detailed reason\n *\n */\nexport declare function assert<T>(input: T, errorFactory?: undefined | ((props: TypeGuardError.IProps) => Error)): T;\n/**\n * Asserts a value type.\n *\n * Asserts a parametric value type and throws a {@link TypeGuardError} with detailed\n * reason, if the parametric value is not following the type `T`. Otherwise, the\n * value is following the type `T`, just input parameter would be returned.\n *\n * If what you want is not asserting but just knowing whether the parametric value is\n * following the type `T` or not, you can choose the {@link is} function instead.\n * Otherwise, you want to know all the errors, {@link validate} is the way to go.\n *\n * On the other and, if you don't want to allow any superfluous property that is not\n * enrolled to the type `T`, you can use {@link assertEquals} function instead.\n *\n * @template T Type of the input value\n * @param input A value to be asserted\n * @param errorFactory Custom error factory. Default is `TypeGuardError`\n * @returns Parametric input value casted as `T`\n * @throws A {@link TypeGuardError} instance with detailed reason\n *\n */\nexport declare function assert<T>(input: unknown, errorFactory?: undefined | ((props: TypeGuardError.IProps) => Error)): T;\n/**\n * Assertion guard of a value type.\n *\n * Asserts a parametric value type and throws a {@link TypeGuardError} with detailed\n * reason, if the parametric value is not following the type `T`. Otherwise, the\n * value is following the type `T`, nothing would be returned, but the input value\n * would be automatically casted to the type `T`. This is the concept of\n * \"Assertion Guard\" of a value type.\n *\n * If what you want is not asserting but just knowing whether the parametric value is\n * following the type `T` or not, you can choose the {@link is} function instead.\n * Otherwise you want to know all the errors, {@link validate} is the way to go.\n * Also, if you want to returns the parametric value when no problem, you can use\n * {@link assert} function instead.\n *\n * On the other and, if you don't want to allow any superfluous property that is not\n * enrolled to the type `T`, you can use {@link assertGuardEquals} function instead.\n *\n * @template T Type of the input value\n * @param input A value to be asserted\n * @param errorFactory Custom error factory. Default is `TypeGuardError`\n * @throws A {@link TypeGuardError} instance with detailed reason\n *\n */\n```\n\n### Example Format:\n\n```ts\nimport { TestValidator } from \"@nestia/e2e\";\nimport api from \"@ORGANIZATION/PROJECT-api\";\nimport { IExampleDto } from \"@ORGANIZATION/PROJECT-api/lib/structures/IExampleDto\";\nimport typia from \"typia\";\n\nexport async function test_api_example_flow(connection: api.IConnection): Promise<void> {\n  const input: IExampleDto = { ... }; // construct valid input\n\n  const result = await api.functional.example.post(connection, input);\n\n  typia.assert(result); // ensure response matches expected type\n  TestValidator.equals(\"result\", exceptFunction)(result.someField);\n}\n\n```  \n\n```ts\nexport async function test_api_hub_cart_commodity_at(\n  connection: api.IConnection,\n): Promise<void> {\n  await test_api_hub_admin_login(pool);\n  await test_api_hub_seller_join(pool);\n  await test_api_hub_customer_create(pool);\n\n  const sale: IHubSale = await generate_random_sale(pool, \"approved\");\n  const commodity: IHubCartCommodity = await generate_random_cart_commodity(\n    pool,\n    sale,\n  );\n\n  const read: IHubCartCommodity =\n    await HubApi.functional.hub.customers.carts.commodities.at(\n      pool.customer,\n      null,\n      commodity.id,\n    );\n  TestValidator.equals(\"at\", exceptSaleKeys)(commodity)(read);\n}\n\nexport const exceptSaleKeys = (key: string): boolean =>\n  key === \"aggregate\" || key === \"swagger\" || key.endsWith(\"_at\");\n\n```  \n\n### Import Guidelines\n\n- **Only import what you actually use**  \n- **Verify all imports exist** in the provided API and DTO files  \n- **Use exact import paths** as specified in the file structure  \n\n```ts\nimport { TestValidator } from \"@nestia/e2e\";\nimport api from \"@ORGANIZATION/PROJECT-api\";\nimport { ISimpleDto } from \"@ORGANIZATION/PROJECT-api/lib/structures/ISimpleDto\";\nimport typia from \"typia\";\n```  \n\n### Data Construction\n\n- **Create simple, valid test data** that matches the DTO structure exactly  \n- **Include all required properties** as defined in the DTO  \n- **Use literal values** rather than complex data generation  \n\n```ts\n// Simple, clear data construction\nconst articleInput: IBbsArticleInput = {\n  title: \"Test Article\",\n  body: \"Test article content\",\n  // Include all required properties from the DTO\n};\n```  \n\n## Error Prevention Rules\n\n### 1. Type Matching\n\n- Always ensure function parameters match the expected types from API definitions  \n- Verify that all required properties are included in request objects  \n- Don't use properties that aren't defined in the DTO types  \n\n### 2. Import Validation\n\n- Only import functions and types that exist in the provided files  \n- Use exact import paths without assumptions  \n- **Follow the exact TestValidator and typia.assert usage patterns** as defined in their type definitions  \n\n### 3. Simple Logic\n\n- Avoid complex type manipulations and filtering functions  \n- Use straightforward validation patterns  \n- Don't use TypeScript directives like `@ts-expect-error` or `@ts-ignore`  \n\n### 4. Null Safety\n\n- Check for null/undefined values before using them  \n- Use optional chaining when appropriate  \n- Handle potential null returns from API calls  \n\n```ts\n// Safe null handling\nif (result && result.data) {\n  typia.assert<IExpectedType>(result.data);\n}\n```  \n\n### 5. Type Safety\n\n- If you declare empty array like `[]`, You must define the type of array together.  \n\nExample:  \n\n  ```typescript\n  const emptyArray: IBbsArticle[] = [];\n\n  TestValidator.equals(\"message\")(\n      [] as IBbsArticleComment[],\n    )(data);\n  ```\n\n\n## Output Format\n\nReturn the following:  \n\n1. **Filename**: Suggested filename for the test (from input)  \n2. **Full Test Code**: A TypeScript file (max 300 lines) containing the E2E test  \n3. **Test Explanation**: Brief paragraph explaining what the test does and how it maps to the scenario  \n4. **Execution Notes**: Any setup steps or dependencies required to run the test  \n\n## Best Practices\n\n- **Keep tests simple and readable** - prioritize clarity over cleverness  \n- **Use only provided API functions and DTO types** - no assumptions  \n- **Create minimal but meaningful tests** that cover the core scenario  \n- **Make tests deterministic** with predictable data and flows  \n- **Include clear comments** for complex business logic only  \n- **Follow naming conventions** (`test_api_[feature]_[action]`)  \n- **Validate inputs and outputs** with simple, direct assertions  \n\n## Error Handling\n\n- If the scenario lacks sufficient detail, ask for clarification   \n- If no matching API function is found for a step, mention it and suggest alternatives from the provided API list  \n- If a required DTO property is missing or unclear, request the complete DTO definition  \n- **Always verify that all used functions and types exist** in the provided files before generating code" /* AutoBeSystemPromptConstant.TEST_PROGRESS */,
+        },
+        {
+            id: (0, uuid_1.v4)(),
+            created_at: new Date().toISOString(),
+            type: "assistantMessage",
+            text: [
+                "You are the world's best E2E test code generator.",
+                "You will be given a **scenario**, and your job is to generate the corresponding **E2E test code** using only the provided API functions and DTOs.",
+                "",
+                "## Rules",
+                "- Follow the base E2E test style strictly. Never use other frameworks like Jest or Mocha.",
+                "- Use `TestValidator.equals(...)` and `typia.assert(...)` to verify results.",
+                "- Use `HubApi.functional.XXX` for all API calls. These are defined in API Files.",
+                "- Use helper functions like `generate_random_xxx(...)` **only if** they already exist in the base test imports.",
+                "- Do not invent new helpers or use utilities that are not explicitly shown.",
+                "- Keep all tests deterministic and reliable.",
+                "",
+                "## File References",
+                "### API Files",
+                "```typescript",
+                JSON.stringify(apiFiles, null, 2),
+                "```",
+                "",
+                "### DTO Files",
+                "```typescript",
+                JSON.stringify(dtoFiles, null, 2),
+                "```",
+                "",
+                "Now generate the E2E test function based on the given scenario.",
+                "Only output a single `async function` named `test_api_{...}`. No explanation, no commentary.",
+            ].join("\n"),
+        },
+    ];
+};
+exports.transformTestProgressHistories = transformTestProgressHistories;
+//# sourceMappingURL=transformTestProgressHistories.js.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"transformTestProgressHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/test/transformTestProgressHistories.ts"],"names":[],"mappings":";;;AACA,+BAA0B;AAInB,MAAM,8BAA8B,GAAG,CAC5C,QAAgC,EAChC,QAAgC,EAGhC,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,mwhBAA0C;SAC/C;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE;gBACJ,mDAAmD;gBACnD,mJAAmJ;gBACnJ,EAAE;gBACF,UAAU;gBACV,2FAA2F;gBAC3F,8EAA8E;gBAC9E,kFAAkF;gBAClF,iHAAiH;gBACjH,6EAA6E;gBAC7E,8CAA8C;gBAC9C,EAAE;gBACF,oBAAoB;gBACpB,eAAe;gBACf,eAAe;gBACf,IAAI,CAAC,SAAS,CAAC,QAAQ,EAAE,IAAI,EAAE,CAAC,CAAC;gBACjC,KAAK;gBACL,EAAE;gBACF,eAAe;gBACf,eAAe;gBACf,IAAI,CAAC,SAAS,CAAC,QAAQ,EAAE,IAAI,EAAE,CAAC,CAAC;gBACjC,KAAK;gBACL,EAAE;gBACF,iEAAiE;gBACjE,8FAA8F;aAC/F,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AA7CW,QAAA,8BAA8B,kCA6CzC"}

package/lib/orchestrate/test/transformTestScenarioHistories.d.ts

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

package/lib/orchestrate/test/transformTestScenarioHistories.js

@@ -0,0 +1,176 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.transformTestScenarioHistories = void 0;
+const uuid_1 = require("uuid");
+const transformTestScenarioHistories = (state, endponits, files) => {
+    if (state.analyze === null)
+        return [
+            {
+                id: (0, uuid_1.v4)(),
+                created_at: new Date().toISOString(),
+                type: "systemMessage",
+                text: [
+                    "Requirement analysis is not yet completed.",
+                    "Don't call the any tool function,",
+                    "but say to process the requirement analysis.",
+                ].join(" "),
+            },
+        ];
+    else if (state.prisma === null)
+        return [
+            {
+                id: (0, uuid_1.v4)(),
+                created_at: new Date().toISOString(),
+                type: "systemMessage",
+                text: [
+                    "Prisma DB schema generation is not yet completed.",
+                    "Don't call the any tool function,",
+                    "but say to process the Prisma DB schema generation.",
+                ].join(" "),
+            },
+        ];
+    else if (state.analyze.step !== state.prisma.step)
+        return [
+            {
+                id: (0, uuid_1.v4)(),
+                created_at: new Date().toISOString(),
+                type: "systemMessage",
+                text: [
+                    "Prisma DB schema generation has not been updated",
+                    "for the latest requirement analysis.",
+                    "Don't call the any tool function,",
+                    "but say to re-process the Prisma DB schema generation.",
+                ].join(" "),
+            },
+        ];
+    else if (state.prisma.compiled.type !== "success")
+        return [
+            {
+                id: (0, uuid_1.v4)(),
+                created_at: new Date().toISOString(),
+                type: "systemMessage",
+                text: [
+                    "Prisma DB schema generation has not been updated",
+                    "for the latest requirement analysis.",
+                    "Don't call the any tool function,",
+                    "but say to re-process the Prisma DB schema generation.",
+                ].join(" "),
+            },
+        ];
+    else if (state.interface === null)
+        return [
+            {
+                id: (0, uuid_1.v4)(),
+                created_at: new Date().toISOString(),
+                type: "systemMessage",
+                text: [
+                    "Interface generation is not yet completed.",
+                    "Don't call the any tool function,",
+                    "but say to process the interface generation.",
+                ].join(" "),
+            },
+        ];
+    return [
+        {
+            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: [
+                "# 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(),
+            type: "systemMessage",
+            text: [
+                "# Result of Interfaced Agent",
+                "- OpenAPI document generation is ready.",
+                "",
+                "Call the provided tool function to generate the user scenarios",
+                "referencing below OpenAPI document.",
+                "",
+                `## OpenAPI Document`,
+                "```json",
+                JSON.stringify(state.interface.document),
+                "```",
+            ].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(endponits, 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;
+//# sourceMappingURL=transformTestScenarioHistories.js.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"transformTestScenarioHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/test/transformTestScenarioHistories.ts"],"names":[],"mappings":";;;AAEA,+BAA0B;AAKnB,MAAM,8BAA8B,GAAG,CAC5C,KAAkB,EAClB,SAAoC,EACpC,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,SAAS,EAAE,IAAI,EAAE,CAAC,CAAC;gBAClC,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"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@autobe/agent",
-  "version": "0.6.0",
+  "version": "0.7.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.6.0"
+    "@autobe/interface": "^0.7.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/compiler": "^0.6.0",
-    "@autobe/filesystem": "^0.6.0"
+    "@autobe/filesystem": "^0.7.0",
+    "@autobe/compiler": "^0.7.0"
   },
   "keywords": [
     "ai",