@autobe/agent 0.9.1 → 0.10.0

package/lib/orchestrate/test/structures/IAutoBeTestCorrectApplication.d.ts

@@ -0,0 +1,121 @@
+export interface IAutoBeTestCorrectApplication {
+    /**
+     * Main entry point for AI Function Call - analyzes compilation errors and
+     * generates corrected E2E test code.
+     *
+     * The AI executes this function to perform the complete error correction
+     * workflow: error-free analysis → compilation error analysis → draft
+     * correction → code review → final corrected implementation. This multi-step
+     * process ensures systematic error resolution while preserving original test
+     * functionality and maintaining code quality.
+     *
+     * The corrector first analyzes the scenario without considering compilation
+     * errors to understand the intended functionality, then incorporates
+     * compilation diagnostics to identify specific issues, and finally produces
+     * corrected code through iterative refinement with comprehensive review and
+     * validation.
+     *
+     * @param props Complete specification for error correction workflow including
+     *   analysis steps, draft implementation, review process, and final code
+     *   generation
+     */
+    rewrite(props: IAutoBeTestCorrectApplication.IProps): void;
+}
+export declare namespace IAutoBeTestCorrectApplication {
+    interface IProps {
+        /**
+         * Step 1: Initial analysis and understanding without compilation error
+         * context.
+         *
+         * AI analyzes the original test scenario, business requirements, and
+         * intended functionality without being influenced by compilation errors.
+         * This clean analysis establishes a clear understanding of what the test
+         * should accomplish, the expected business workflow, and the correct API
+         * integration patterns.
+         *
+         * This step ensures that error correction doesn't lose sight of the
+         * original test purpose and helps maintain the intended business logic
+         * while addressing technical compilation issues. The AI develops a
+         * comprehensive understanding of the test requirements before diving into
+         * error-specific details.
+         *
+         * Workflow: Scenario understanding → Business logic analysis → Intended
+         * functionality mapping
+         */
+        think_without_compile_error: string;
+        /**
+         * Step 2: Compilation error analysis and root cause identification.
+         *
+         * AI re-analyzes the scenario and implementation with full awareness of
+         * compilation errors and diagnostic information. This step involves
+         * systematic examination of error messages, identification of error
+         * patterns, and understanding of how compilation issues relate to the
+         * intended functionality.
+         *
+         * The AI correlates compilation diagnostics with the original requirements
+         * to understand where the implementation diverged from correct TypeScript
+         * usage while maintaining the business logic intent. This analysis forms
+         * the foundation for targeted error correction strategies.
+         *
+         * Workflow: Error diagnostic analysis → Root cause identification →
+         * Correction strategy planning
+         */
+        think_again_with_compile_error: string;
+        /**
+         * Step 3: Draft corrected TypeScript E2E test code implementation.
+         *
+         * AI generates the first corrected version of the test code based on error
+         * analysis and correction strategies. This draft addresses all identified
+         * compilation errors while preserving the original business logic and test
+         * workflow. The code must be compilation-error-free and follow all
+         * established conventions.
+         *
+         * The implementation incorporates lessons learned from error analysis to
+         * produce properly typed, syntactically correct code that maintains the
+         * intended test functionality. All type safety requirements and framework
+         * conventions must be followed in this corrected implementation.
+         *
+         * Workflow: Error correction → TypeScript implementation → Functional
+         * preservation Critical: Must resolve all compilation errors while
+         * maintaining original test intent
+         */
+        draft: string;
+        /**
+         * Step 4: Code review and correction validation.
+         *
+         * AI performs a comprehensive review of the corrected draft implementation,
+         * validating that all compilation errors have been resolved and that the
+         * code maintains the original functionality. This review examines both
+         * technical correctness and business logic preservation.
+         *
+         * The review process includes verification of TypeScript compilation
+         * compatibility, API integration correctness, test workflow completeness,
+         * and adherence to all quality standards. Any remaining issues or potential
+         * improvements are identified for incorporation into the final
+         * implementation.
+         *
+         * Workflow: Draft validation → Compilation verification → Functionality
+         * review → Quality assessment
+         */
+        review: string;
+        /**
+         * Step 5: Final production-ready corrected test code.
+         *
+         * AI produces the final, polished version of the corrected test code
+         * incorporating all review feedback and validation results. This code
+         * represents the completed error correction, guaranteed to compile
+         * successfully while preserving all original test functionality and
+         * business logic.
+         *
+         * The final implementation resolves all compilation issues, maintains
+         * strict type safety, follows all established conventions, and delivers a
+         * production-ready test that accurately validates the intended API
+         * behaviors and user workflows.
+         *
+         * Workflow: Review integration → Final refinement → Production-ready
+         * implementation This is the ultimate deliverable that will replace the
+         * compilation-failed code.
+         */
+        final: string;
+    }
+}

package/lib/orchestrate/test/structures/IAutoBeTestCorrectApplication.js

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

package/lib/orchestrate/test/structures/IAutoBeTestCorrectApplication.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"IAutoBeTestCorrectApplication.js","sourceRoot":"","sources":["../../../../src/orchestrate/test/structures/IAutoBeTestCorrectApplication.ts"],"names":[],"mappings":""}

package/lib/orchestrate/test/structures/IAutoBeTestFunction.d.ts

@@ -0,0 +1,8 @@
+import { AutoBeTestScenario } from "@autobe/interface";
+import { IAutoBeTestScenarioArtifacts } from "./IAutoBeTestScenarioArtifacts";
+export interface IAutoBeTestFunction {
+    artifacts: IAutoBeTestScenarioArtifacts;
+    scenario: AutoBeTestScenario;
+    location: string;
+    script: string;
+}

package/lib/{utils/types/BackoffOptions.js → orchestrate/test/structures/IAutoBeTestFunction.js}

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

package/lib/orchestrate/test/structures/IAutoBeTestFunction.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"IAutoBeTestFunction.js","sourceRoot":"","sources":["../../../../src/orchestrate/test/structures/IAutoBeTestFunction.ts"],"names":[],"mappings":""}

package/lib/orchestrate/test/structures/IAutoBeTestScenarioApplication.d.ts

@@ -13,25 +13,29 @@ export declare namespace IAutoBeTestScenarioApplication {
         scenarioGroups: IAutoBeTestScenarioApplication.IScenarioGroup[];
     }
     interface IScenarioGroup {
-        /** Target API endpoint to test. */
+        /**
+         * Target API endpoint to test.
+         *
+         * This must be **unique** across all scenario groups. An endpoint is
+         * identified by its `path` and `method` combination.
+         *
+         * Multiple test scenarios may exist for a single endpoint.
+         */
         endpoint: AutoBeOpenApi.IEndpoint;
-        /** Array of test scenarios. */
+        /**
+         * An array of test scenarios associated with the given endpoint.
+         *
+         * Each scenario represents a specific test case for the same `path` and
+         * `method`.
+         */
         scenarios: IScenario[];
     }
     /**
      * Represents a test scenario for a single API operation.
      *
-     * This interface extends `AutoBeOpenApi.IEndpoint`, inheriting its HTTP
-     * method and path information, and adds two key properties:
-     *
-     * - `draft`: A free-form, human-readable test scenario description for the API
-     *   endpoint.
-     * - `dependsOn`: A list of other API endpoints that must be invoked beforehand
-     *   in order to prepare the context for this test. Each dependency includes
-     *   the purpose of the dependency.
-     *
-     * This structure is intended to help organize test specifications for complex
-     * workflows and ensure that all prerequisites are explicitly declared.
+     * This interface defines a structured, user-centric test draft that includes
+     * a descriptive function name, a detailed scenario draft, and logical
+     * dependencies on other endpoints required for context or setup.
      */
     interface IScenario {
         /**
@@ -39,7 +43,7 @@ export declare namespace IAutoBeTestScenarioApplication {
          * be tested. This should include both successful and failure scenarios,
          * business rule validations, edge cases, and any sequence of steps
          * necessary to perform the test. A subsequent agent will use this draft to
-         * generate multiple test scenarios.
+         * generate multiple concrete test cases.
          */
         draft: string;
         /**
@@ -102,18 +106,24 @@ export declare namespace IAutoBeTestScenarioApplication {
          */
         functionName: string;
         /**
-         * A list of other API endpoints that must be executed before this test
-         * scenario. This helps express dependencies such as data creation or
-         * authentication steps required to reach the intended test state.
+         * A list of other API endpoints that this scenario logically depends on.
+         *
+         * These dependencies represent context or prerequisite conditions, such as
+         * authentication, resource creation, or data setup, that are relevant to
+         * the test. This list is not a strict execution order — if ordering is
+         * important, it must be described explicitly in the `purpose`.
          */
-        dependsOn: IDependsOn[];
+        dependencies: IDependencies[];
     }
-    interface IDependsOn {
-        /** Target API endpoint that must be executed before the main operation. */
+    interface IDependencies {
+        /** Target API endpoint that this scenario depends on. */
         endpoint: AutoBeOpenApi.IEndpoint;
         /**
-         * A concise exscenarioation of why this API call is required before
-         * executing the test for the main operation.
+         * A concise explanation of why this API call is relevant or required for
+         * the main test scenario.
+         *
+         * This should describe the contextual or setup role of the dependency, such
+         * as creating necessary data or establishing user authentication.
          *
          * Example: "Creates a category so that a product can be linked to it during
          * creation."

package/lib/orchestrate/test/structures/IAutoBeTestScenarioArtifacts.d.ts

@@ -1,4 +1,6 @@
+import { AutoBeOpenApi } from "@autobe/interface";
 export interface IAutoBeTestScenarioArtifacts {
+    document: AutoBeOpenApi.IDocument;
     sdk: Record<string, string>;
     dto: Record<string, string>;
     e2e: Record<string, string>;

package/lib/orchestrate/test/structures/IAutoBeTestWriteApplication.d.ts

@@ -0,0 +1,112 @@
+export interface IAutoBeTestWriteApplication {
+    /**
+     * Main entry point for AI Function Call - generates complete E2E test code.
+     *
+     * The AI executes this function to perform the entire test generation
+     * workflow: scenario analysis → draft implementation → code review → final
+     * code production. This structured approach ensures high-quality,
+     * compilation-error-free test code.
+     *
+     * @param props Complete specification for test generation including scenario,
+     *   domain, and implementation steps
+     */
+    write(props: IAutoBeTestWriteApplication.IProps): void;
+}
+export declare namespace IAutoBeTestWriteApplication {
+    interface IProps {
+        /**
+         * Step 1: Strategic test planning and scenario analysis.
+         *
+         * AI analyzes the given test scenario and creates a comprehensive
+         * implementation strategy. This planning phase is crucial for generating
+         * well-structured, maintainable test code. The AI must define test
+         * methodology, data preparation, execution flow, and validation logic
+         * before proceeding to code implementation.
+         *
+         * Workflow: Input scenario → Strategic analysis → Detailed test plan
+         */
+        scenario: string;
+        /**
+         * Step 2: Functional domain classification for test organization.
+         *
+         * AI determines the appropriate domain category based on the scenario
+         * analysis. This classification drives file structure, test categorization,
+         * and logical grouping. The domain must be a single, lowercase word that
+         * represents the primary API resource.
+         *
+         * Workflow: Scenario analysis → Domain identification → Test organization
+         * structure
+         */
+        domain: string;
+        /**
+         * Step 3: Initial TypeScript E2E test code implementation.
+         *
+         * AI generates the first working version of the test code based on the
+         * strategic plan. This draft must be compilation-error-free and follow
+         *
+         * @nestia/e2e framework conventions. The code should implement all planned
+         * test scenarios with proper async/await patterns, type safety, and
+         * comprehensive error handling.
+         *
+         * Workflow: Strategic plan → TypeScript implementation → Functional test
+         * code
+         *
+         * Critical: NO import statements, start directly with 'export async function'
+         */
+        draft: string;
+        /**
+         * Step 4: Code review and quality assessment.
+         *
+         * AI performs a thorough review of the draft implementation, examining:
+         *
+         * **Compilation & Syntax:**
+         *
+         * - TypeScript compilation errors and type mismatches
+         * - Syntax errors and missing semicolons/brackets
+         * - Correct function signatures and parameter types
+         *
+         * **Framework Compliance:**
+         *
+         * - @nestia/e2e framework conventions adherence
+         * - Proper API SDK function calling patterns
+         * - Correct use of typia.assert() and TestValidator functions
+         *
+         * **Business Logic & Test Coverage:**
+         *
+         * - Complete workflow implementation (authentication → data setup → main test
+         *   → validation)
+         * - Realistic business scenarios and user journeys
+         * - Edge case handling and error condition testing
+         * - Proper data dependencies and cleanup procedures
+         *
+         * **Code Quality & Security:**
+         *
+         * - Type safety violations (any, @ts-ignore, etc.)
+         * - Variable naming and code organization
+         * - Performance considerations and resource management
+         * - Security best practices in test data generation
+         *
+         * Workflow: Draft code → Systematic analysis → Specific improvement
+         * recommendations
+         *
+         * The review must identify concrete issues with line-by-line feedback and
+         * provide actionable solutions for each problem discovered.
+         */
+        review: string;
+        /**
+         * Step 5: Final production-ready test code.
+         *
+         * AI produces the final, polished version of the test code incorporating
+         * all review feedback. This code represents the completed test
+         * implementation, ready for production deployment. All identified issues
+         * must be resolved, and the code must meet the highest quality standards.
+         *
+         * Workflow: Review feedback → Code refinement → Production-ready
+         * implementation
+         *
+         * This is the ultimate deliverable that will be used in the actual test
+         * suite.
+         */
+        final: string;
+    }
+}

package/lib/orchestrate/test/structures/IAutoBeTestWriteApplication.js

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

package/lib/orchestrate/test/structures/IAutoBeTestWriteApplication.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"IAutoBeTestWriteApplication.js","sourceRoot":"","sources":["../../../../src/orchestrate/test/structures/IAutoBeTestWriteApplication.ts"],"names":[],"mappings":""}

package/lib/orchestrate/test/structures/IAutoBeTestWriteResult.d.ts

@@ -0,0 +1,7 @@
+import { AutoBeTestScenario, AutoBeTestWriteEvent } from "@autobe/interface";
+import { IAutoBeTestScenarioArtifacts } from "./IAutoBeTestScenarioArtifacts";
+export interface IAutoBeTestWriteResult {
+    scenario: AutoBeTestScenario;
+    artifacts: IAutoBeTestScenarioArtifacts;
+    event: AutoBeTestWriteEvent;
+}

package/lib/orchestrate/test/structures/IAutoBeTestWriteResult.js

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

package/lib/orchestrate/test/structures/IAutoBeTestWriteResult.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"IAutoBeTestWriteResult.js","sourceRoot":"","sources":["../../../../src/orchestrate/test/structures/IAutoBeTestWriteResult.ts"],"names":[],"mappings":""}

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

@@ -1,3 +1,4 @@
 import { IAgenticaHistoryJson } from "@agentica/core";
-import { IAutoBeTestScenarioArtifacts } from "./structures/IAutoBeTestScenarioArtifacts";
-export declare const transformTestCorrectHistories: (artifacts: IAutoBeTestScenarioArtifacts) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;
+import { IAutoBeTypeScriptCompileResult } from "@autobe/interface";
+import { IAutoBeTestFunction } from "./structures/IAutoBeTestFunction";
+export declare const transformTestCorrectHistories: (func: IAutoBeTestFunction, failure: IAutoBeTypeScriptCompileResult.IFailure) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;

package/lib/orchestrate/test/transformTestCorrectHistories.js

@@ -2,46 +2,33 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.transformTestCorrectHistories = void 0;
 const uuid_1 = require("uuid");
-const transformTestCorrectHistories = (artifacts) => {
-    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#### Importing namespace rule\n\n```ts\n// \u274C Incorrect usage: importing inner types directly from a namespaced type\nimport {\n  IShoppingSaleInquiryComment,\n  IShoppingSaleInquiryComment_ICreate,\n  IShoppingSaleInquiryComment_IRequest,\n} from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSaleInquiryComment\";\n\n```\n\n```ts\n// \u2705 Correct usage: import only the namespace and access inner types via dot notation\nimport {\n  IShoppingSaleInquiryComment,\n} from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSaleInquiryComment\";\n\ntype A = IShoppingSaleInquiryComment.ICreate // correct!\ntype B = IShoppingSaleInquiryComment.IRequest // correct!\n```\n\n- \uD83D\uDCA1 Rule: When working with types defined inside a namespace, import only the namespace and access inner types using dot notation (e.g., Namespace.InnerType).\nAvoid importing inner types directly, as it breaks encapsulation and may cause naming conflicts or improper typings.\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/PROJECT-api'\nCannot find module '@nestia/PROJECT-api'\nCannot find module '@anyorg/PROJECT-api'\n// Fix: Replace with @ORGANIZATION/PROJECT-api\n\n// Error Pattern 2: Missing organization prefix  \nCannot find module '@PROJECT-api'\nCannot find module 'PROJECT-api'\n// Fix: Add @ORGANIZATION/ prefix\n\n// Error Pattern 3: Structure imports with wrong org\nCannot find module '@wrtnlabs/PROJECT-api/lib/structures/IType'\nCannot find module '@nestia/PROJECT-api/lib/structures/IType'\n// Fix: Replace with @ORGANIZATION/PROJECT-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/PROJECT-api\";\nimport { IBbsArticle } from \"@wrtnlabs/PROJECT-api/lib/structures/IBbsArticle\";\nimport { IAttachmentFile } from \"@PROJECT-api/lib/structures/IAttachmentFile\";\n\n// AFTER (All fixed consistently):\nimport api from \"@ORGANIZATION/PROJECT-api\";\nimport { IBbsArticle } from \"@ORGANIZATION/PROJECT-api/lib/structures/IBbsArticle\";\nimport { IAttachmentFile } from \"@ORGANIZATION/PROJECT-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/PROJECT-api\";                    // Issue 1\nimport { IBbsArticle } from \"@wrtnlabs/PROJECT-api/lib/structures/IBbsArticle\";  // Issue 2  \nimport { IUser } from \"@PROJECT-api/lib/structures/IUser\";  // Issue 3\n\n// Output: ALL issues fixed simultaneously:\nimport api from \"@ORGANIZATION/PROJECT-api\";\nimport { IBbsArticle } from \"@ORGANIZATION/PROJECT-api/lib/structures/IBbsArticle\";\nimport { IUser } from \"@ORGANIZATION/PROJECT-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(artifacts.sdk),
-                "```",
-                "",
-                "### DTO Files",
-                "```typescript",
-                JSON.stringify(artifacts.dto),
-                "```",
-                "",
-                "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"),
-        },
-    ];
-};
+const transformTestWriteHistories_1 = require("./transformTestWriteHistories");
+const transformTestCorrectHistories = (func, failure) => [
+    ...(0, transformTestWriteHistories_1.transformTestWriteHistories)(func.scenario, func.artifacts),
+    {
+        id: (0, uuid_1.v4)(),
+        created_at: new Date().toISOString(),
+        type: "assistantMessage",
+        text: [
+            "## Generated TypeScript Code",
+            "```typescript",
+            func.script,
+            "```",
+            "",
+            "## Compile Errors",
+            "Fix the compilation error in the provided code.",
+            "",
+            "```json",
+            JSON.stringify(failure.diagnostics),
+            "```",
+        ].join("\n"),
+    },
+    {
+        id: (0, uuid_1.v4)(),
+        created_at: new Date().toISOString(),
+        type: "systemMessage",
+        text: "# E2E Test Code Compilation Error Fix System Prompt\n\n## 1. Role and Responsibility\n\nYou are an AI assistant specialized in analyzing TypeScript compilation errors and fixing E2E test code to achieve successful compilation. Your primary task is to analyze compilation diagnostics, understand the root causes of errors, and generate corrected code that compiles without errors while maintaining the original test functionality and business logic.\n\n## 2. Input Materials Overview\n\nYou will receive the following context through the conversation messages:\n\n- **Original system prompt**: Complete guidelines and requirements used by the initial code writing agent\n- **Original input materials**: Test scenario, API specifications, DTO types, and other materials used for initial code generation\n- **Generated code**: The TypeScript E2E test code that failed to compile\n- **Compilation diagnostics**: Detailed TypeScript compilation error information\n\nYour job is to analyze the compilation errors and produce corrected code that follows all the original guidelines while resolving compilation issues.\n\n## 3. TypeScript Compilation Results Analysis\n\nThe compilation error information follows this detailed structure:\n\n```typescript\n/**\n * Result of TypeScript compilation and validation operations.\n *\n * This union type represents all possible outcomes when the TypeScript compiler\n * processes generated code from the Test and Realize agents. The compilation\n * results enable AI self-correction through detailed feedback mechanisms while\n * ensuring that all generated code meets production standards and integrates\n * seamlessly with the TypeScript ecosystem.\n *\n * The compilation process validates framework integration, type system\n * integrity, dependency resolution, and build compatibility. Success results\n * indicate production-ready code, while failure results provide detailed\n * diagnostics for iterative refinement through the AI feedback loop.\n *\n * @author Samchon\n */\nexport type IAutoBeTypeScriptCompileResult =\n  | IAutoBeTypeScriptCompileResult.ISuccess\n  | IAutoBeTypeScriptCompileResult.IFailure\n  | IAutoBeTypeScriptCompileResult.IException;\n\nexport namespace IAutoBeTypeScriptCompileResult {\n  /**\n   * Successful compilation result with generated JavaScript output.\n   *\n   * Represents the ideal outcome where TypeScript compilation completed without\n   * errors and produced clean JavaScript code ready for execution. This result\n   * indicates that the generated TypeScript code meets all production\n   * standards, integrates correctly with frameworks and dependencies, and\n   * maintains complete type safety throughout the application stack.\n   */\n  export interface ISuccess {\n    /** Discriminator indicating successful compilation. */\n    type: \"success\";\n  }\n\n  /**\n   * Compilation failure with detailed diagnostic information and partial\n   * output.\n   *\n   * Represents cases where TypeScript compilation encountered errors or\n   * warnings that prevent successful code generation. This result provides\n   * comprehensive diagnostic information to enable AI agents to understand\n   * specific issues and implement targeted corrections through the iterative\n   * refinement process.\n   */\n  export interface IFailure {\n    /** Discriminator indicating compilation failure. */\n    type: \"failure\";\n\n    /**\n     * Detailed compilation diagnostics for error analysis and correction.\n     *\n     * Contains comprehensive information about compilation errors, warnings,\n     * and suggestions that occurred during the TypeScript compilation process.\n     * Each diagnostic includes file location, error category, diagnostic codes,\n     * and detailed messages that enable AI agents to understand and resolve\n     * specific compilation issues.\n     */\n    diagnostics: IDiagnostic[];\n  }\n\n  /**\n   * Unexpected exception during the compilation process.\n   *\n   * Represents cases where the TypeScript compilation process encountered an\n   * unexpected runtime error or system exception that prevented normal\n   * compilation operation. These cases indicate potential issues with the\n   * compilation environment or unexpected edge cases that should be\n   * investigated.\n   */\n  export interface IException {\n    /** Discriminator indicating compilation exception. */\n    type: \"exception\";\n\n    /**\n     * The raw error or exception that occurred during compilation.\n     *\n     * Contains the original error object or exception details for debugging\n     * purposes. This information helps developers identify the root cause of\n     * unexpected compilation failures and improve system reliability while\n     * maintaining the robustness of the automated development pipeline.\n     */\n    error: unknown;\n  }\n\n  /**\n   * Detailed diagnostic information for compilation issues.\n   *\n   * Provides comprehensive details about specific compilation problems\n   * including file locations, error categories, diagnostic codes, and\n   * descriptive messages. This information is essential for AI agents to\n   * understand compilation failures and implement precise corrections during\n   * the iterative development process.\n   *\n   * @author Samchon\n   */\n  export interface IDiagnostic {\n    /**\n     * Source file where the diagnostic was generated.\n     *\n     * Specifies the TypeScript source file that contains the issue, or null if\n     * the diagnostic applies to the overall compilation process rather than a\n     * specific file. This information helps AI agents target corrections to the\n     * appropriate source files during the refinement process.\n     */\n    file: string | null;\n\n    /**\n     * Category of the diagnostic message.\n     *\n     * Indicates the severity and type of the compilation issue, enabling AI\n     * agents to prioritize fixes and understand the impact of each diagnostic.\n     * Errors must be resolved for successful compilation, while warnings and\n     * suggestions can guide code quality improvements.\n     */\n    category: DiagnosticCategory;\n\n    /**\n     * TypeScript diagnostic code for the specific issue.\n     *\n     * Provides the official TypeScript diagnostic code that identifies the\n     * specific type of compilation issue. This code can be used to look up\n     * detailed explanations and resolution strategies in TypeScript\n     * documentation or automated correction systems.\n     */\n    code: number | string;\n\n    /**\n     * Character position where the diagnostic begins in the source file.\n     *\n     * Specifies the exact location in the source file where the issue starts,\n     * or undefined if the diagnostic doesn't apply to a specific location. This\n     * precision enables AI agents to make targeted corrections without\n     * affecting unrelated code sections.\n     */\n    start: number | undefined;\n\n    /**\n     * Length of the text span covered by this diagnostic.\n     *\n     * Indicates how many characters from the start position are affected by\n     * this diagnostic, or undefined if the diagnostic doesn't apply to a\n     * specific text span. This information helps AI agents understand the scope\n     * of corrections needed for each issue.\n     */\n    length: number | undefined;\n\n    /**\n     * Human-readable description of the compilation issue.\n     *\n     * Provides a detailed explanation of the compilation problem in natural\n     * language that AI agents can analyze to understand the issue and formulate\n     * appropriate corrections. The message text includes context and\n     * suggestions for resolving the identified problem.\n     */\n    messageText: string;\n  }\n\n  /**\n   * Categories of TypeScript diagnostic messages.\n   *\n   * Defines the severity levels and types of compilation diagnostics that can\n   * be generated during TypeScript compilation. These categories help AI agents\n   * prioritize fixes and understand the impact of each compilation issue on the\n   * overall code quality and functionality.\n   *\n   * @author Samchon\n   */\n  export type DiagnosticCategory =\n    | \"warning\" // Issues that don't prevent compilation but indicate potential problems\n    | \"error\" // Critical issues that prevent successful compilation and must be fixed\n    | \"suggestion\" // Recommendations for code improvements that enhance quality\n    | \"message\"; // Informational messages about the compilation process\n}\n```\n\n## 4. Error Analysis and Correction Strategy\n\n### 4.1. Strict Correction Requirements\n\n**FORBIDDEN CORRECTION METHODS - NEVER USE THESE:**\n- Never use `any` type to bypass type checking\n- Never use `@ts-ignore` comments to suppress compilation errors\n- Never use `@ts-expect-error` comments to bypass type validation\n- Never use `as any` type assertions to force type compatibility\n- Never use `satisfies any` expressions to skip type validation\n- Never use any other type safety bypass mechanisms\n\n**REQUIRED CORRECTION APPROACH:**\n- Fix errors by using correct types from provided DTO definitions\n- Resolve type mismatches by following exact API SDK function signatures\n- Address compilation issues through proper TypeScript syntax and typing\n- Maintain strict type safety throughout the entire correction process\n\nThe goal is to achieve genuine compilation success through proper TypeScript usage, not to hide errors through type system suppression.\n\n**IMPLEMENTATION FEASIBILITY REQUIREMENT:**\nIf the original code attempts to implement functionality that cannot be realized with the provided API functions and DTO types, **REMOVE those parts** during error correction. Only fix and retain code that is technically feasible with the actual materials provided.\n\n### 4.2. Diagnostic Analysis Process\n\n**Systematic Error Analysis:**\n1. **Error Categorization**: Focus on `\"error\"` category diagnostics first, as these prevent successful compilation\n2. **Error Priority Assessment**: \n   - Type system violations and missing type definitions\n   - API function signature mismatches\n   - Import/export issues and module resolution\n   - Syntax errors and malformed expressions\n   - Logic errors and incorrect implementations\n3. **Location Mapping**: Use `file`, `start`, and `length` to pinpoint exact error locations in the source code\n4. **Error Code Analysis**: Reference TypeScript diagnostic codes to understand specific error types\n5. **Message Interpretation**: Analyze `messageText` to understand the root cause and required corrections\n\n**Root Cause Identification:**\n- Analyze each diagnostic's file location, error code, and message\n- Identify patterns in errors that suggest systematic issues\n- Determine if errors are related to incorrect API usage, type mismatches, or logic problems\n- Check for cascading errors where fixing one issue resolves multiple diagnostics\n\n### 4.3. Systematic Error Resolution\n\n**Error Resolution Strategy:**\n- Prioritize errors over warnings and suggestions\n- Fix errors that may be causing cascading issues first\n- Maintain all original functionality while resolving compilation issues\n- Ensure the corrected code follows all guidelines from the original system prompt\n- Verify that fixes don't introduce new compilation errors\n\n**Common Error Resolution Patterns:**\n- **Type Mismatches**: Use correct types from provided DTO definitions\n- **Function Signature Errors**: Match exact API SDK function signatures\n- **Import Errors**: Remember no import statements should be used in E2E tests\n- **Authentication Issues**: Use only actual authentication APIs provided in materials\n- **TestValidator Errors**: Apply proper curried function syntax and parameter order\n- **typia.random() Errors**: Always provide explicit generic type arguments to `typia.random<T>()`\n\n### 4.4. Special Compilation Error Patterns and Solutions\n\n### 4.4.1. Non-existent API SDK Function Calls\n\nYou must only use API SDK functions that actually exist in the provided materials.\n\nIf the error message (`ITypeScriptCompileResult.IDiagnostic.messageText`) shows something like:\n```\nProperty 'update' does not exist on type 'typeof import(\"src/api/functional/bbs/articles/index\")'.\n```\n\nThis indicates an attempt to call a non-existent API SDK function. Refer to the following list of available API functions and replace the incorrect function call with the proper one:\n\n{{API_SDK_FUNCTIONS}}\n\n**Solution approach:**\n- Locate the failing function call in your code\n- Find the correct function name from the table above\n- Replace the non-existent function call with the correct API SDK function\n- Ensure the function signature matches the provided SDK specification\n\n### 4.4.2. Undefined DTO Type References\n\nIf the error message shows:\n```\nCannot find module '@ORGANIZATION/PROJECT-api/lib/structures/ISomeDtoTypeName.ts' or its corresponding type declarations\n```\n\nThis means you are using DTO types that don't exist in the provided materials. You must only use DTO types that are explicitly defined in the input materials.\n\nRefer to the following DTO definitions and replace undefined types with the correct ones:\n\n{{API_DTO_SCHEMAS}}\n\n**Solution approach:**\n- Identify the undefined type name in the error message\n- Search for the correct type name in the DTO definitions above\n- Replace the undefined type reference with the correct DTO type\n- Ensure the type usage matches the provided type definition structure\n\n### 4.4.3. Complex Error Message Validation\n\nIf the test scenario suggests implementing complex error message validation or using fallback closures with `TestValidator.error()`, **DO NOT IMPLEMENT** these test cases. Focus only on simple error occurrence testing.\n\nIf you encounter code like:\n```typescript\n// WRONG: Don't implement complex error message validation\nawait TestValidator.error(\"limit validation error\")(\n  async () => {\n    await api.functional.bbs.categories.patch(connection, {\n      body: { page: 1, limit: 1000000 } satisfies IBbsCategories.IRequest,\n    });\n  },\n  (error) => { // \u2190 Remove this fallback closure\n    if (!error?.message?.toLowerCase().includes(\"limit\"))\n      throw new Error(\"Error message validation\");\n  },\n);\n```\n\n**Solution approach:**\n- Remove any fallback closure (second parameter) from `TestValidator.error()` calls\n- Simplify to only test whether an error occurs or not\n- Do not attempt to validate specific error messages, error types, or error properties\n- Focus on runtime business logic errors with properly typed, valid TypeScript code\n\n```typescript\n// CORRECT: Simple error occurrence testing\nTestValidator.error(\"limit validation error\")(() => {\n  return api.functional.bbs.categories.patch(connection, {\n    body: { page: 1, limit: 1000000 } satisfies IBbsCategories.IRequest,\n  });\n});\n```\n\n**Rule:** Only test scenarios that involve runtime errors with properly typed, valid TypeScript code. Skip any test scenarios that require detailed error message validation or complex error inspection logic.\n\n### 4.4.4. Type-safe Equality Assertions\n\nWhen fixing `TestValidator.equals()` and `TestValidator.notEquals()` calls, be careful about parameter order. The generic type is determined by the first parameter, so the second parameter must be assignable to the first parameter's type.\n\n**IMPORTANT: Use actual-first, expected-second pattern**\nFor best type compatibility, use the actual value (from API responses or variables) as the first parameter and the expected value as the second parameter:\n\n```typescript\n// CORRECT: actual value first, expected value second\nconst member: IMember = await api.functional.membership.join(connection, ...);\nTestValidator.equals(\"no recommender\")(member.recommender)(null); // member.recommender is IRecommender | null, can accept null \u2713\n\n// WRONG: expected value first, actual value second - may cause type errors\nTestValidator.equals(\"no recommender\")(null)(member.recommender); // null cannot accept IRecommender | null \u2717\n\n// CORRECT: String comparison example\nTestValidator.equals(\"user ID matches\")(createdUser.id)(expectedId); // actual first, expected second \u2713\n\n// CORRECT: Object comparison example  \nTestValidator.equals(\"user data matches\")(actualUser)(expectedUserData); // actual first, expected second \u2713\n```\n\n**Additional type compatibility examples:**\n```typescript\n// CORRECT: First parameter type can accept second parameter\nconst user = { id: \"123\", name: \"John\", email: \"john@example.com\" };\nconst userSummary = { id: \"123\", name: \"John\" };\n\nTestValidator.equals(\"user contains summary data\")(user)(userSummary); // user type can accept userSummary \u2713\nTestValidator.equals(\"user summary matches\")(userSummary)(user); // WRONG: userSummary cannot accept user with extra properties \u2717\n\n// CORRECT: Extract specific properties for comparison\nTestValidator.equals(\"user ID matches\")(user.id)(userSummary.id); // string = string \u2713\nTestValidator.equals(\"user name matches\")(user.name)(userSummary.name); // string = string \u2713\n\n// CORRECT: Union type parameter order\nconst value: string | null = getSomeValue();\nTestValidator.equals(\"value should be null\")(value)(null); // string | null can accept null \u2713\nTestValidator.equals(\"value should be null\")(null)(value); // WRONG: null cannot accept string | null \u2717\n```\n\n**Solution approach:**\n- Use the pattern `TestValidator.equals(\"description\")(actualValue)(expectedValue)` where actualValue is typically from API responses\n- If compilation errors occur with `TestValidator.equals(title)(x)(y)` because `y` cannot be assigned to `x`'s type, reverse the order to `TestValidator.equals(title)(y)(x)`\n- Alternatively, extract specific properties for comparison to ensure type compatibility\n- Apply the same logic to `TestValidator.notEquals()` calls\n\n### 4.4.5. Unimplementable Scenario Components\n\nIf the original code attempts to implement functionality that cannot be realized with the provided API functions and DTO types, **REMOVE those parts** during error correction. Only fix and retain code that is technically feasible with the actual materials provided.\n\n**Examples of unimplementable functionality to REMOVE:**\n- Code attempting to call API functions that don't exist in the provided SDK function definitions\n- Code using DTO properties that don't exist in the provided type definitions\n- Code implementing features that require API endpoints not available in the materials\n- Code with data filtering or searching using parameters not supported by the actual DTO types\n\n```typescript\n// REMOVE: If code tries to call non-existent bulk ship function\n// await api.functional.orders.bulkShip(connection, {...}); \u2190 Remove this entirely\n\n// REMOVE: If code tries to use non-existent date filter properties\n// { startDate: \"2024-01-01\", endDate: \"2024-12-31\" } \u2190 Remove these properties\n```\n\n**Solution approach:**\n1. **Identify unimplementable code**: Look for compilation errors related to non-existent API functions or DTO properties\n2. **Verify against provided materials**: Check if the functionality exists in the actual API SDK functions and DTO definitions\n3. **Remove entire code blocks**: Delete the unimplementable functionality rather than trying to fix it\n4. **Maintain test flow**: Ensure the remaining code still forms a coherent test workflow\n5. **Focus on feasible functionality**: Preserve and fix only the parts that can be properly implemented\n\n### 4.4.6. Incorrect TestValidator Curried Function Usage\n\nIf you encounter incorrect usage of `TestValidator` functions that are not properly curried, fix them to use the correct curried function call pattern.\n\n**Common incorrect patterns to fix:**\n```typescript\n// WRONG: Passing all parameters at once\nTestValidator.equals(title, x, y);\nTestValidator.notEquals(title, x, y);\nTestValidator.error(title, asyncFunction);\n\n// WRONG: Partial currying with multiple parameters\nTestValidator.equals(title)(x, y);\nTestValidator.notEquals(title)(x, y);\n\n// WRONG: Missing currying steps\nTestValidator.predicate(title, condition);\n```\n\n**Correct curried function patterns:**\n```typescript\n// CORRECT: Fully curried TestValidator calls\nTestValidator.equals(title)(x)(y);\nTestValidator.notEquals(title)(x)(y);\nTestValidator.predicate(title)(condition);\nTestValidator.error(title)(asyncFunction);\n```\n\n**Solution approach:**\n1. **Identify incorrect patterns**: Look for compilation errors related to incorrect parameter counts or function signatures\n2. **Apply proper currying**: Convert all parameters to sequential function calls\n3. **Maintain type safety**: Ensure parameter order follows the type-safe guidelines (first parameter determines generic type)\n4. **Verify function signatures**: Check that each curried call receives exactly one parameter\n\n**Rule:** All `TestValidator` functions are curried and must be called with the pattern `TestValidator.functionName(param1)(param2)(param3)` rather than `TestValidator.functionName(param1, param2, param3)`.\n\n### 4.4.7. Missing Generic Type Arguments in typia.random()\n\nIf you encounter compilation errors related to `typia.random()` calls without explicit generic type arguments, fix them by adding the required type parameters.\n\n**CRITICAL: Always provide generic type arguments to typia.random()**\nThe `typia.random()` function requires explicit generic type arguments. This is a common source of compilation errors in E2E tests.\n\n**Common error patterns to fix:**\n```typescript\n// WRONG: Missing generic type argument causes compilation error\nconst x = typia.random(); // \u2190 Compilation error\nconst x: string & tags.Format<\"uuid\"> = typia.random(); // \u2190 Still compilation error\n\n// CORRECT: Always provide explicit generic type arguments\nconst x = typia.random<string & tags.Format<\"uuid\">>();\nconst x: string = typia.random<string & tags.Format<\"uuid\">>();\nconst x: string & tags.Format<\"uuid\"> = typia.random<string & tags.Format<\"uuid\">>();\n```\n\n**Solution approach:**\n1. **Identify missing generic arguments**: Look for compilation errors related to `typia.random()` calls\n2. **Add explicit type parameters**: Ensure all `typia.random()` calls have `<TypeDefinition>` generic arguments\n3. **Use appropriate types**: Match the generic type with the intended data type for the test\n4. **Verify compilation**: Check that the fix resolves the compilation error\n\n**Rule:** Always use the pattern `typia.random<TypeDefinition>()` with explicit generic type arguments, regardless of variable type annotations.\n\n## 5. Correction Requirements\n\nYour corrected code must:\n\n**Compilation Success:**\n- Resolve all TypeScript compilation errors identified in the diagnostics\n- Compile successfully without any errors or warnings\n- Maintain proper TypeScript syntax and type safety\n\n**Functionality Preservation:**\n- Maintain the original test functionality and business logic\n- Preserve comprehensive test coverage and validation logic\n- Keep all realistic and implementable test scenarios\n\n**Code Quality:**\n- Follow all conventions and requirements from the original system prompt\n- Use proper TestValidator curried function syntax\n- Apply actual-first, expected-second pattern for equality assertions\n- Remove only unimplementable functionality, not working code\n\n**Systematic Approach:**\n- Analyze compilation diagnostics systematically\n- Address root causes rather than just symptoms\n- Ensure fixes don't introduce new compilation errors\n- Verify the corrected code maintains test coherence\n\nGenerate corrected code that achieves successful compilation while maintaining all original requirements and functionality." /* AutoBeSystemPromptConstant.TEST_CORRECT */.replace("{{API_DTO_SCHEMAS}}", transformTestWriteHistories_1.transformTestWriteHistories.structures(func.artifacts)).replace("{{API_SDK_FUNCTIONS}}", transformTestWriteHistories_1.transformTestWriteHistories.functional(func.artifacts)),
+    },
+];
 exports.transformTestCorrectHistories = transformTestCorrectHistories;
 //# sourceMappingURL=transformTestCorrectHistories.js.map

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

@@ -1 +1 @@
-{"version":3,"file":"transformTestCorrectHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/test/transformTestCorrectHistories.ts"],"names":[],"mappings":";;;AACA,+BAA0B;AAKnB,MAAM,6BAA6B,GAAG,CAC3C,SAAuC,EAGvC,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,wraAAyC;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,SAAS,CAAC,GAAG,CAAC;gBAC7B,KAAK;gBACL,EAAE;gBACF,eAAe;gBACf,eAAe;gBACf,IAAI,CAAC,SAAS,CAAC,SAAS,CAAC,GAAG,CAAC;gBAC7B,KAAK;gBACL,EAAE;gBACF,qEAAqE;gBACrE,8FAA8F;aAC/F,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AA5CW,QAAA,6BAA6B,iCA4CxC"}
+{"version":3,"file":"transformTestCorrectHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/test/transformTestCorrectHistories.ts"],"names":[],"mappings":";;;AAEA,+BAA0B;AAI1B,+EAA4E;AAErE,MAAM,6BAA6B,GAAG,CAC3C,IAAyB,EACzB,OAAgD,EAGhD,EAAE,CAAC;IACH,GAAG,IAAA,yDAA2B,EAAC,IAAI,CAAC,QAAQ,EAAE,IAAI,CAAC,SAAS,CAAC;IAC7D;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE,kBAAkB;QACxB,IAAI,EAAE;YACJ,8BAA8B;YAC9B,eAAe;YACf,IAAI,CAAC,MAAM;YACX,KAAK;YACL,EAAE;YACF,mBAAmB;YACnB,iDAAiD;YACjD,EAAE;YACF,SAAS;YACT,IAAI,CAAC,SAAS,CAAC,OAAO,CAAC,WAAW,CAAC;YACnC,KAAK;SACN,CAAC,IAAI,CAAC,IAAI,CAAC;KACb;IACD;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE,eAAe;QACrB,IAAI,EAAE,k+uBAAwC,OAAO,CACnD,qBAAqB,EACrB,yDAA2B,CAAC,UAAU,CAAC,IAAI,CAAC,SAAS,CAAC,CACvD,CAAC,OAAO,CACP,uBAAuB,EACvB,yDAA2B,CAAC,UAAU,CAAC,IAAI,CAAC,SAAS,CAAC,CACvD;KACF;CACF,CAAC;AArCW,QAAA,6BAA6B,iCAqCxC"}

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

@@ -1,7 +1,8 @@
 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>;
+export declare function transformTestWriteHistories(scenario: AutoBeTestScenario, artifacts: IAutoBeTestScenarioArtifacts): Array<IAgenticaHistoryJson.ISystemMessage>;
+export declare namespace transformTestWriteHistories {
+    function structures(artifacts: IAutoBeTestScenarioArtifacts): string;
+    function functional(artifacts: IAutoBeTestScenarioArtifacts): string;
+}