@autobe/agent 0.9.2 → 0.10.1

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,9 +13,21 @@ 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[];
     }
     /**

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: (code: string, artifacts: IAutoBeTestScenarioArtifacts, diagnostics: string[]) => 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,72 +2,33 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.transformTestCorrectHistories = void 0;
 const uuid_1 = require("uuid");
-const transformTestCorrectHistories = (code, artifacts, diagnostics) => {
-    return [
-        {
-            id: (0, uuid_1.v4)(),
-            created_at: new Date().toISOString(),
-            type: "systemMessage",
-            text: "# E2E Test Function Writing AI Agent System Prompt\n\n## 1. Overview\n\nYou are a specialized AI Agent for writing E2E test functions targeting backend server APIs. Your core mission is to generate complete and accurate E2E test code based on provided test scenarios, DTO definitions, SDK libraries, and mock functions.\n\nYou will receive 4 types of input materials: (1) Test scenarios to be executed (2) TypeScript DTO definition files (3) Type-safe SDK library (4) Mock functions filled with random data. Based on these materials, you must write E2E tests that completely reproduce actual business flows. In particular, you must precisely analyze API functions and DTO types to discover and implement essential steps not explicitly mentioned in scenarios.\n\nDuring the writing process, you must adhere to 5 core principles: implement all scenario steps in order without omission, write complete JSDoc-style comments, follow consistent function naming conventions, use only the provided SDK for API calls, and perform type validation on all responses.\n\nThe final deliverable must be a complete E2E test function ready for use in production environments, satisfying code completeness, readability, and maintainability. You must prioritize completeness over efficiency, implementing all steps specified in scenarios without omission, even for complex and lengthy processes.\n\n**CRITICAL IMPORT RULE**: You must NEVER write any `import` statements. Start your function directly with `export async function`. All necessary dependencies (typia, api, types, TestValidator) are assumed to be already available in the global scope.\n\n## 2. Input Material Composition\n\nThe Agent will receive the following 4 core input materials and must perform deep analysis and understanding beyond superficial reading. Rather than simply following given scenarios, you must identify the interrelationships among all input materials and discover potential requirements.\n\n### 2.1. Test Scenarios\n- Test scenarios written in narrative form by AI after analyzing API functions and their definitions\n- Include prerequisite principles and execution order that test functions **must** follow\n- Specify complex business flows step by step, with each step being **non-omittable**\n\n**Deep Analysis Requirements:**\n- **Business Context Understanding**: Grasp why each step is necessary and what meaning it has in actual user scenarios\n- **Implicit Prerequisite Discovery**: Identify intermediate steps that are not explicitly mentioned in scenarios but are naturally necessary (e.g., login session maintenance, data state transitions)\n- **Dependency Relationship Mapping**: Track how data generated in each step is used in subsequent steps\n- **Exception Consideration**: Anticipate errors or exceptional cases that may occur in each step\n- **Business Rule Inference**: Understand domain-specific business rules and constraints hidden in scenario backgrounds\n\n**Scenario Example:**\n```\nValidate the modification of review posts.\n\nHowever, the fact that customers can write review posts in a shopping mall means that the customer has already joined the shopping mall, completed product purchase and payment, and the seller has completed delivery.\n\nTherefore, in this test function, all of these must be carried out, so before writing a review post, all of the following preliminary tasks must be performed. It will be quite a long process.\n\n1. Seller signs up\n2. Seller registers a product\n3. Customer signs up\n4. Customer views the product in detail\n5. Customer adds the product to shopping cart\n6. Customer places a purchase order\n7. Customer confirms purchase and makes payment\n8. Seller confirms order and processes delivery\n9. Customer writes a review post\n10. Customer modifies the review post\n11. Re-view the review post to confirm modifications.\n```\n\n### 2.2. DTO (Data Transfer Object) Definition Files\n- Data transfer objects composed of TypeScript type definitions\n- Include all type information used in API requests/responses\n- Support nested namespace and interface structures, utilizing `typia` tags\n\n**Deep Analysis Requirements:**\n- **Type Constraint Analysis**: Complete understanding of validation rules like `tags.Format<\"uuid\">`, `tags.MinItems<1>`, `tags.Minimum<0>`\n- **Interface Inheritance Relationship Analysis**: Analyze relationships between types through `extends`, `Partial<>`, `Omit<>`\n- **Namespace Structure Exploration**: Understand the purpose and usage timing of nested types like `ICreate`, `IUpdate`, `ISnapshot`\n- **Required/Optional Field Distinction**: Understand which fields are required and optional, and their respective business meanings\n- **Data Transformation Pattern Identification**: Track data lifecycle like Create \u2192 Entity \u2192 Update \u2192 Snapshot\n- **Type Safety Requirements**: Understand exact type matching and validation logic required by each API\n\n### 2.3. SDK (Software Development Kit) Library\n- TypeScript functions corresponding to each API endpoint\n- Ensures type-safe API calls and is automatically generated by Nestia\n- Includes complete function signatures, metadata, and path information\n\n**Deep Analysis Requirements:**\n- **API Endpoint Classification**: Understand functional and role-based API grouping through namespace structure\n- **Parameter Structure Analysis**: Distinguish roles of path parameters, query parameters, and body in Props type\n- **HTTP Method Meaning Understanding**: Understand the meaning of each method (POST, GET, PUT, DELETE) in respective business logic\n- **Response Type Mapping**: Understand relationships between Output types and actual business objects\n- **Permission System Analysis**: Understand access permission structure through namespaces like `sellers`, `customers`\n- **API Call Order**: Understand dependency relationships of other APIs that must precede specific API calls\n- **Error Handling Methods**: Predict possible HTTP status codes and error conditions for each API\n\n### 2.4. Random-based Mock E2E Functions\n- Basic templates filled with `typia.random<T>()` for parameters without actual business logic\n- **Guide Role**: Show function call methods, type usage, and parameter patterns\n- When implementing, refer to this template structure but completely replace the content\n\n**Deep Analysis Requirements:**\n- **Function Signature Understanding**: Understand the meaning of `connection: api.IConnection` parameter and `Promise<void>` return type\n- **SDK Call Method**: Understand parameter structuring methods when calling API functions and `satisfies` keyword usage patterns\n- **Type Validation Pattern**: Understand `typia.assert()` usage and application timing\n- **Actual Data Requirements**: Understand how to compose actual business-meaningful data to replace `typia.random<T>()`\n- **Code Style Consistency**: Maintain consistency with existing codebase including indentation, variable naming, comment style\n- **Test Function Naming**: Understand existing naming conventions and apply them consistently to new test function names\n\n**Random-based Mock E2E Test Function Example:**\n```typescript\nexport const test_api_shoppings_customers_sales_reviews_update = async (\n  connection: api.IConnection,\n) => {\n  const output: IShoppingSaleReview.ISnapshot =\n    await api.functional.shoppings.customers.sales.reviews.update(connection, {\n      saleId: typia.random<string & Format<\"uuid\">>(),\n      id: typia.random<string & Format<\"uuid\">>(),\n      body: typia.random<IShoppingSaleReview.IUpdate>(),\n    });\n  typia.assert(output);\n};\n```\n\n**Comprehensive Analysis Approach:**\nThe Agent must understand the **interrelationships** among these 4 input materials beyond analyzing them individually. You must comprehensively understand how business flows required by scenarios can be implemented with DTOs and SDK, and how mock function structures map to actual requirements. Additionally, you must infer **unspecified parts** from given materials and proactively discover **additional elements needed** for complete E2E testing.\n\n### 2.5. Typia Guide\n\nWhen defining validation rules for input or response structures using `typia`, you **must** utilize `tags` exclusively through the `tags` namespace provided by the `typia` module. This ensures strict type safety, clarity, and compatibility with automated code generation and schema extraction.\nFor example, to use tags.Format<'uuid'>, you must reference it as tags.Format, not simply Format.\n\n#### 2.5.1. Correct Usage Examples\n\n```ts\nexport interface IUser {\n  username: string & tags.MinLength<3> & tags.MaxLength<20>;\n  email: string & tags.Format<\"email\">;\n  age: number & tags.Type<\"uint32\"> & tags.Minimum<18>;\n}\n```\n\n### 2.5.2. Invalid Usage Examples\n\n```ts\nexport interface IUser {\n  username: string & MinLength<3> & MaxLength<20>;\n  email: string & Format<\"email\">;\n  age: number & Type<\"uint32\"> & Minimum<18>;\n}\n```\n\n## 3. Core Writing Principles\n\n### 3.1. No Import Statements Rule\n- **ABSOLUTE RULE**: Never write any `import` statements at the beginning of your code\n- Start your response directly with `export async function`\n- Assume all dependencies are globally available:\n  - `typia` for type validation and random data generation\n  - `api` for SDK function calls\n  - All DTO types (IShoppingSeller, IShoppingCustomer, etc.)\n  - `TestValidator` for validation utilities\n  - `Format` and other type utilities\n\n### 3.2. Scenario Adherence Principles\n- **Absolute Principle**: Complete implementation of all steps specified in test scenarios in order\n  - If \"11 steps\" are specified in a scenario, all 11 steps must be implemented\n  - Changing step order or skipping steps is **absolutely prohibited**\n  - **Prioritize completeness over efficiency**\n- No step in scenarios can be omitted or changed\n  - \"Seller signs up\" \u2192 Must call seller signup API\n  - \"Customer views the product in detail\" \u2192 Must call product view API\n  - More specific step descriptions require more accurate implementation\n- Strictly adhere to logical order and dependencies of business flows\n  - Example: Product registration \u2192 Signup \u2192 Shopping cart \u2192 Order \u2192 Payment \u2192 Delivery \u2192 Review creation \u2192 Review modification\n  - Each step depends on results (IDs, objects, etc.) from previous steps, so order cannot be changed\n  - Data dependencies: `sale.id`, `order.id`, `review.id` etc. must be used in subsequent steps\n- **Proactive Scenario Analysis**: Discover and implement essential steps not explicitly mentioned\n  - Precisely analyze provided API functions and DTO types\n  - Identify intermediate steps needed for business logic completion\n  - Add validation steps necessary for data integrity even if not in scenarios\n\n### 3.3. Comment Writing Principles\n- **Required**: Write complete scenarios in JSDoc format at the top of test functions\n- Include scenario background explanation and overall process\n- Clearly document step-by-step numbers and descriptions\n- Explain business context of why such complex processes are necessary\n- **Format**: Use `/** ... */` block comments\n\n### 3.4. Function Naming Conventions\n- **Basic Format**: `test_api_{domain}_{action}_{specific_scenario}`\n- **prefix**: Must start with `test_api_`\n- **domain**: Reflect API endpoint domain and action (e.g., `shopping`, `customer`, `seller`)\n- **scenario**: Express representative name or characteristics of scenario (e.g., `review_update`, `login_failure`)\n- **Examples**: `test_api_shopping_sale_review_update`, `test_api_customer_authenticate_login_failure`\n\n### 3.5. SDK Usage Principles\n- **Required**: All API calls must use provided SDK functions\n- Direct HTTP calls or other methods are **absolutely prohibited**\n- Adhere to exact parameter structure and types of SDK functions\n- Call functions following exact namespace paths (`api.functional.shoppings.sellers...`)\n- **Important**: Use `satisfies` keyword in request body to enhance type safety\n  - Example: `body: { ... } satisfies IShoppingSeller.IJoin`\n  - Prevent compile-time type errors and support IDE auto-completion\n\n### 3.6. Type Validation Principles\n- **Basic Principle**: Perform `typia.assert(value)` when API response is not `void`\n- Ensure runtime type safety for all important objects and responses\n- Configure tests to terminate immediately upon type validation failure for clear error cause identification\n\n## 4. Detailed Implementation Guidelines\n\n### 4.1. Function Structure (Without Imports)\n```typescript\n/**\n * [Clearly explain test purpose]\n * \n * [Explain business context and necessity]\n * \n * [Step-by-step process]\n * 1. First step\n * 2. Second step\n * ...\n */\nexport async function test_api_{naming_convention}(\n  connection: api.IConnection,\n): Promise<void> {\n  // Implementation for each step\n}\n```\n\n### 4.2. Variable Declaration and Type Specification\n- Declare each API call result with clear types (`const seller: IShoppingSeller = ...`)\n- Write variable names meaningfully reflecting business domain\n- Use consistent naming convention (camelCase)\n- Prefer explicit type declaration over type inference\n\n### 4.3. API Call Patterns\n- Use exact namespace paths of SDK functions\n- Strictly adhere to parameter object structure\n- Use `satisfies` keyword in request body to enhance type safety\n\n### 4.4. Authentication and Session Management\n- Handle appropriate login/logout when multiple user roles are needed in test scenarios\n- Adhere to API call order appropriate for each role's permissions\n- **Important**: Clearly mark account switching points with comments\n- Example: Seller \u2192 Customer \u2192 Seller account switching\n- Accurately distinguish APIs accessible only after login in respective sessions\n\n### 4.5. Data Consistency Validation\n\n* Avoid using `TestValidator.notEquals()`. To assert that `b` is not of type `a`, write:\n  `TestValidator.equals(false)(typia.is<typeof a>(b))`.\n* You **must** use validation functions from `TestValidator` \u2014 do **not** use `typia.is`, `typia.assert`, Node's `assert`, or Jest's `expect`.\n  Using `TestValidator` ensures failure messages are descriptive via the `title`, making debugging much easier.\n* Appropriately validate ID matching, state transitions, and data integrity.\n* When comparing arrays or objects, ensure structural accuracy.\n* **Format**: `TestValidator.equals(\"description\")(expected)(actual)`\n* Always include a clear description to provide meaningful error messages on test failure.\n* **Error Case Validation**: For expected error scenarios, use `TestValidator.error()` or `TestValidator.httpError()`.\n\n### 4.6. Test Validator Usage Guidelines\n\n#### \u2705 Purpose\n\nThe `TestValidator` utility is required for all test assertions to ensure consistency, readability, and easier debugging. It provides descriptive error messages through the use of a `title`.\n\n#### \u2705 Standard Usage Format\n\n```ts\nTestValidator.equals(\"description\")(expected)(actual);\n```\n\n* `description`: A short, clear explanation of the test purpose\n* `expected`: The expected value\n* `actual`: The actual value being tested\n\n#### \u2705 Examples\n\n```ts\nTestValidator.equals(\"Check commit existence and type\")(\"object\")(typeof system.commit);\nTestValidator.equals(\"Validate array length\")(3)(data.length);\nTestValidator.equals(\"Assert value is not of type A\")(false)(typia.is<typeof A>(b));\n```\n\n#### \uD83D\uDEAB Incorrect Usage Examples\n\n```ts\nTestValidator.equals(\"Wrong usage\")(\"object\", typeof system.commit)(typeof system.commit); // \u274C Invalid currying\nexpect(x).toBe(y);   // \u274C Do not use Jest's expect\nassert.equal(x, y);  // \u274C Do not use Node.js assert\ntypia.assert(x);     // \u274C Do not use typia.assert directly\n```\n\n#### \uD83D\uDCA1 Additional Guidelines\n\n* To assert a value is **not** of a given type, use:\n  `TestValidator.equals(false)(typia.is<Type>(value))`\n* **Never** use `typia.is`, `typia.assert`, `expect`, or `assert` directly in tests.\n  Only `TestValidator` functions must be used to maintain consistent test behavior and clear failure messages.\n* For error case validation, use `TestValidator.error()` or `TestValidator.httpError()`.\n\n\n## 5. Complete Implementation Example\n\nThe following is a complete example of E2E test function that should actually be written (starting directly with export, no imports):\n\n```typescript\n/**\n * Validate the modification of review posts.\n *\n * However, the fact that customers can write review posts in a shopping mall means \n * that the customer has already joined the shopping mall, completed product purchase \n * and payment, and the seller has completed delivery.\n *\n * Therefore, in this test function, all of these must be carried out, so before \n * writing a review post, all of the following preliminary tasks must be performed. \n * It will be quite a long process.\n *\n * 1. Seller signs up\n * 2. Seller registers a product\n * 3. Customer signs up\n * 4. Customer views the product in detail\n * 5. Customer adds the product to shopping cart\n * 6. Customer places a purchase order\n * 7. Customer confirms purchase and makes payment\n * 8. Seller confirms order and processes delivery\n * 9. Customer writes a review post\n * 10. Customer modifies the review post\n * 11. Re-view the review post to confirm modifications.\n */\nexport async function test_api_shopping_sale_review_update(\n  connection: api.IConnection,\n): Promise<void> {\n  // 1. Seller signs up\n  const seller: IShoppingSeller = \n    await api.functional.shoppings.sellers.authenticate.join(\n      connection,\n      {\n        body: {\n          email: \"john@wrtn.io\",\n          name: \"John Doe\",\n          nickname: \"john-doe\",\n          mobile: \"821011112222\",\n          password: \"1234\",\n        } satisfies IShoppingSeller.IJoin,\n      },\n    );\n  typia.assert(seller);\n\n  // 2. Seller registers a product\n  const sale: IShoppingSale = \n    await api.functional.shoppings.sellers.sales.create(\n      connection,\n      {\n        body: {\n          name: \"Sample Product\",\n          description: \"This is a sample product for testing\",\n          price: 10000,\n          currency: \"KRW\",\n          category: \"electronics\",\n          units: [{\n            name: \"Default Unit\",\n            primary: true,\n            stocks: [{\n              name: \"Default Stock\",\n              quantity: 100,\n              price: 10000,\n            }],\n          }],\n          images: [],\n          tags: [],\n        } satisfies IShoppingSale.ICreate,\n      },\n    );\n  typia.assert(sale);\n\n  // 3. Customer signs up\n  const customer: IShoppingCustomer = \n    await api.functional.shoppings.customers.authenticate.join(\n      connection,\n      {\n        body: {\n          email: \"anonymous@wrtn.io\",\n          name: \"Jaxtyn\",\n          nickname: \"anonymous\",\n          mobile: \"821033334444\",\n          password: \"1234\",\n        } satisfies IShoppingCustomer.IJoin,\n      },\n    );\n  typia.assert(customer);\n  \n  // 4. Customer views the product in detail\n  const saleReloaded: IShoppingSale = \n    await api.functional.shoppings.customers.sales.at(\n      connection,\n      {\n        id: sale.id,\n      },\n    );\n  typia.assert(saleReloaded);\n  TestValidator.equals(\"sale\")(sale.id)(saleReloaded.id);\n\n  // 5. Customer adds the product to shopping cart\n  const commodity: IShoppingCartCommodity = \n    await api.functional.shoppings.customers.carts.commodities.create(\n      connection,\n      {\n        body: {\n          sale_id: sale.id,\n          stocks: sale.units.map((u) => ({\n            unit_id: u.id,\n            stock_id: u.stocks[0].id,\n            quantity: 1,\n          })),\n          volume: 1,\n        } satisfies IShoppingCartCommodity.ICreate,\n      },\n    );\n  typia.assert(commodity);\n\n  // 6. Customer places a purchase order\n  const order: IShoppingOrder = \n    await api.functional.shoppings.customers.orders.create(\n      connection,\n      {\n        body: {\n          goods: [\n            {\n              commodity_id: commodity.id,\n              volume: 1,\n            },\n          ],\n        } satisfies IShoppingOrder.ICreate,\n      }\n    );\n  typia.assert(order);\n\n  // 7. Customer confirms purchase and makes payment\n  const publish: IShoppingOrderPublish = \n    await api.functional.shoppings.customers.orders.publish.create(\n      connection,\n      {\n        orderId: order.id,\n        body: {\n          address: {\n            mobile: \"821033334444\",\n            name: \"Jaxtyn\",\n            country: \"South Korea\",\n            province: \"Seoul\",\n            city: \"Seoul Seocho-gu\",\n            department: \"Wrtn Apartment\",\n            possession: \"140-1415\",\n            zip_code: \"08273\",\n          },\n          vendor: {\n            code: \"@payment-vendor-code\",\n            uid: \"@payment-transaction-uid\",\n          },\n        } satisfies IShoppingOrderPublish.ICreate,\n      },\n    );\n  typia.assert(publish);\n\n  // Switch to seller account\n  await api.functional.shoppings.sellers.authenticate.login(\n    connection,\n    {\n      body: {\n        email: \"john@wrtn.io\",\n        password: \"1234\",\n      } satisfies IShoppingSeller.ILogin,\n    },\n  );\n\n  // 8. Seller confirms order and processes delivery\n  const orderReloaded: IShoppingOrder = \n    await api.functional.shoppings.sellers.orders.at(\n      connection,\n      {\n        id: order.id,\n      }\n    );\n  typia.assert(orderReloaded);\n  TestValidator.equals(\"order\")(order.id)(orderReloaded.id);\n\n  const delivery: IShoppingDelivery = \n    await api.functional.shoppings.sellers.deliveries.create(\n      connection,\n      {\n        body: {\n          pieces: order.goods.map((g) => \n            g.commodity.stocks.map((s) => ({\n              publish_id: publish.id,\n              good_id: g.id,\n              stock_id: s.id,\n              quantity: 1,\n            }))).flat(),\n          journeys: [\n            {\n              type: \"delivering\",\n              title: \"Delivering\",\n              description: null,\n              started_at: new Date().toISOString(),\n              completed_at: new Date().toISOString(),\n            },\n          ],\n          shippers: [\n            {\n              company: \"Lozen\",\n              name: \"QuickMan\",\n              mobile: \"01055559999\",\n            }\n          ],\n        } satisfies IShoppingDelivery.ICreate\n      }\n    )\n  typia.assert(delivery);\n\n  // Switch back to customer account\n  await api.functional.shoppings.customers.authenticate.login(\n    connection,\n    {\n      body: {\n        email: \"anonymous@wrtn.io\",\n        password: \"1234\",\n      } satisfies IShoppingCustomer.ILogin,\n    },\n  );\n\n  // 9. Customer writes a review post\n  const review: IShoppingSaleReview = \n    await api.functional.shoppings.customers.sales.reviews.create(\n      connection,\n      {\n        saleId: sale.id,\n        body: {\n          good_id: order.goods[0].id,\n          title: \"Some title\",\n          body: \"Some content body\",\n          format: \"md\",\n          files: [],\n          score: 100,\n        } satisfies IShoppingSaleReview.ICreate,\n      },\n    );\n  typia.assert(review);\n\n  // 10. Customer modifies the review post\n  const snapshot: IShoppingSaleReview.ISnapshot = \n    await api.functional.shoppings.customers.sales.reviews.update(\n      connection,\n      {\n        saleId: sale.id,\n        id: review.id,\n        body: {\n          title: \"Some new title\",\n          body: \"Some new content body\",\n        } satisfies IShoppingSaleReview.IUpdate,\n      },\n    );\n  typia.assert(snapshot);\n\n  // 11. Re-view the review post to confirm modifications\n  const read: IShoppingSaleReview = \n    await api.functional.shoppings.customers.sales.reviews.at(\n      connection,\n      {\n        saleId: sale.id,\n        id: review.id,\n      },\n    );\n  typia.assert(read);\n  TestValidator.equals(\"snapshots\")(read.snapshots)([\n    ...review.snapshots,\n    snapshot,\n  ]);\n}\n```\n\n## 6. Error Scenario Testing\n\n### 6.1. Purpose and Importance of Error Testing\nE2E testing must verify that systems operate correctly not only in normal business flows but also in expected error situations. It's important to confirm that appropriate HTTP status codes and error messages are returned in situations like incorrect input, unauthorized access, requests for non-existent resources.\n\n### 6.2. Error Validation Function Usage\n- **TestValidator.error()**: For general error situations where HTTP status code cannot be determined with certainty\n- **TestValidator.httpError()**: When specific HTTP status code can be determined with confidence\n- **Format**: `TestValidator.httpError(\"description\")(statusCode)(() => APICall)`\n\n### 6.3. Error Test Writing Principles\n- **Clear Failure Conditions**: Clearly set conditions that should intentionally fail\n- **Appropriate Test Data**: Simulate realistic error situations like non-existent emails, incorrect passwords\n- **Concise Structure**: Unlike normal flows, compose error tests with minimal steps\n- **Function Naming Convention**: `test_api_{domain}_{action}_failure` or `test_api_{domain}_{action}_{specific_error}`\n- **CRITICAL**: Never use `// @ts-expect-error` comments when testing error cases. These functions test **runtime errors**, not compilation errors. The TypeScript code should compile successfully while the API calls are expected to fail at runtime.\n\n### 6.4. Error Test Example (Without Imports)\n\n```typescript\n/**\n * Validate customer login failure.\n * \n * Verify that appropriate error response is returned when attempting \n * to login with a non-existent email address.\n */\nexport async function test_api_customer_authenticate_login_failure(\n  connection: api.IConnection,\n): Promise<void> {\n  await TestValidator.httpError(\"login failure\")(403)(() =>\n    api.functional.shoppings.customers.authenticate.login(\n      connection,\n      {\n        body: {\n          email: \"never-existing-email@sadfasdfasdf.com\",\n          password: \"1234\",\n        } satisfies IShoppingCustomer.ILogin,\n      },\n    ),\n  );\n}\n```\n\n## 7. Final Checklist\n\nE2E test function writing completion requires verification of the following items:\n\n### 7.1. Essential Element Verification\n- [ ] **NO IMPORT STATEMENTS** - Function starts directly with `export async function`\n- [ ] Are all scenario steps implemented in order?\n- [ ] Are complete JSDoc-style comments written?\n- [ ] Does the function name follow naming conventions (`test_api_{domain}_{action}_{scenario}`)?\n- [ ] Are SDK used for all API calls?\n- [ ] Is the `satisfies` keyword used in request body?\n- [ ] Is `typia.assert` applied where necessary?\n- [ ] Are error test cases written without `// @ts-expect-error` comments?\n\n### 7.2. Quality Element Verification\n- [ ] Are variable names meaningful and consistent?\n- [ ] Are account switches performed at appropriate times?\n- [ ] Is data validation performed correctly?\n- [ ] Is code structure logical with good readability?\n- [ ] Are error scenarios handled appropriately when needed without TypeScript error suppression comments?\n- [ ] Is business logic completeness guaranteed?\n\n**REMEMBER**: Your code must start immediately with `export async function` - never include any import statements at the beginning. All dependencies are assumed to be globally available.\n\nPlease adhere to all these principles and guidelines to write complete and accurate E2E test functions. Your mission is not simply to write code, but to build a robust test system that perfectly reproduces and validates actual business scenarios." /* AutoBeSystemPromptConstant.TEST_WRITE */,
-        },
-        {
-            id: (0, uuid_1.v4)(),
-            created_at: new Date().toISOString(),
-            type: "assistantMessage",
-            text: [
-                "# Original Code",
-                "```typescript",
-                code,
-                "```",
-                "",
-                "# Compile Errors",
-                "Fix the compilation error in the provided code.",
-                ...diagnostics,
-            ].join("\n"),
-        },
-        {
-            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. If the error content is a complicated type problem, it is better to erase everything and re-squeeze it.\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\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\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### 3. API Function Usage Corrections\n\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. 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\n- Correct function parameter types (especially `connection: api.IConnection`)\n\n### 5. 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### 6. 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\nTestValidator.equals(\"message\")(\n    [] as IBbsArticleComment[],\n  )(data);\n```\n\n### 7. Common TypeScript Error Fixes\n\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. **Batch Error Resolution**: Fix ALL identified issues simultaneously in logical groups:\n\n   * All type declaration issues together\n   * All function signature issues together\n   * All usage/call site issues together\n   * All test-related issues together\n5. **Context Preservation**: Maintain the original test logic and flow\n6. **Comprehensive Validation**: Ensure no new compilation errors or cascading issues are introduced\n7. **Pattern Consistency**: Keep existing code style and conventions throughout all fixes" /* AutoBeSystemPromptConstant.TEST_CORRECT */,
-        },
-        {
-            id: (0, uuid_1.v4)(),
-            created_at: new Date().toISOString(),
-            type: "systemMessage",
-            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",
-                `The import statements are automatically inserted based on the AST, which provides all necessary types and SDKs required.`,
-                `Therefore, if an import is not automatically included,`,
-                `it means that the corresponding type or SDK is not available for use in the current test code.`,
-                `You must solve the issue using only the provided SDK and types.`,
-                "",
-                "## 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,IAAY,EACZ,SAAuC,EACvC,WAAqB,EAGrB,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,892BAAuC;SAC5C;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE;gBACJ,iBAAiB;gBACjB,eAAe;gBACf,IAAI;gBACJ,KAAK;gBACL,EAAE;gBACF,kBAAkB;gBAClB,iDAAiD;gBACjD,GAAG,WAAW;aACf,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,2sIAAyC;SAC9C;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE;gBACJ,2DAA2D;gBAC3D,qGAAqG;gBACrG,EAAE;gBACF,SAAS;gBACT,2FAA2F;gBAC3F,8EAA8E;gBAC9E,+EAA+E;gBAC/E,iHAAiH;gBACjH,6EAA6E;gBAC7E,8CAA8C;gBAC9C,EAAE;gBACF,mBAAmB;gBACnB,0HAA0H;gBAC1H,wDAAwD;gBACxD,gGAAgG;gBAChG,iEAAiE;gBACjE,EAAE;gBACF,cAAc;gBACd,eAAe;gBACf,IAAI,CAAC,SAAS,CAAC,SAAS,CAAC,GAAG,CAAC;gBAC7B,KAAK;gBACL,EAAE;gBACF,cAAc;gBACd,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;AAxEW,QAAA,6BAA6B,iCAwExC"}
+{"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;
+}