@autobe/agent 0.17.1 → 0.19.1

package/lib/{orchestrate/realize/structures/IAutoBeRealizeCoderApplication.d.ts → agent/src/orchestrate/realize/structures/IAutoBeRealizeWriteApplication.d.ts}

@@ -1,73 +1,8 @@
-import { AutoBeOpenApi } from "@autobe/interface";
-import { FAILED } from "./IAutoBeRealizeFailedSymbol";
-export interface IAutoBeRealizeCoderApplication {
-    programming: (input: IAutoBeRealizeCoderApplication.IProps) => void;
+export interface IAutoBeRealizeWriteApplication {
+    coding: (next: IAutoBeRealizeWriteApplication.IProps) => void;
 }
-export declare namespace IAutoBeRealizeCoderApplication {
-    /**
-     * Properties for the component or function that consumes the output of the
-     * code generation pipeline.
-     */
+export declare namespace IAutoBeRealizeWriteApplication {
     interface IProps {
-        /**
-         * The detailed output of the code generation process, containing all phases
-         * from planning to final implementation of a TypeScript provider function.
-         */
-        output: Omit<IAutoBeRealizeCoderApplication.RealizeCoderOutput, "filename">;
-    }
-    /**
-     * Represents the complete output of a code generation pipeline. Each field
-     * corresponds to a stage in the Chain of Thought (CoT) process for generating
-     * a production-quality TypeScript function.
-     *
-     * All fields contain TypeScript code strings and follow these rules:
-     *
-     * - All code must be valid TypeScript or structurally valid even if incomplete.
-     * - Each phase builds upon the previous one and must resolve specific concerns.
-     * - All phases must follow system conventions around structure, typing, and
-     *   logic.
-     */
-    interface RealizeCoderOutput {
-        /** @ignore */
-        filename: string;
-        /**
-         * Error Analysis Phase (Optional)
-         *
-         * 🔍 Analyzes TypeScript compilation errors from previous attempts.
-         *
-         * This field should contain a detailed analysis of any TypeScript errors
-         * encountered, with root cause identification and resolution strategies:
-         *
-         * Common Error Patterns to Analyze:
-         *
-         * 1. **"Property does not exist" (TS2353)**:
-         *
-         *    - Root Cause: Using fields that don't exist in Prisma schema
-         *    - Example: Using `deleted_at` when the field doesn't exist in the model
-         *    - Resolution: Remove the non-existent field or use hard delete instead
-         * 2. **"Type 'void' is not assignable" (TS2322)**:
-         *
-         *    - Root Cause: Using `typia.assertGuard` instead of `typia.assert`
-         *    - `assertGuard` returns void, `assert` returns the validated value
-         *    - Resolution: Change `typia.assertGuard<T>()` to `typia.assert<T>()`
-         * 3. **"Type 'Date' is not assignable to type 'string &
-         *    Format<'date-time'>'"**:
-         *
-         *    - Root Cause: Assigning native Date objects to string fields
-         *    - Resolution: Use `toISOStringSafe(dateValue)` for all date conversions
-         * 4. **Complex Prisma Type Errors**:
-         *
-         *    - Root Cause: Nested operations with incompatible types
-         *    - Resolution: Use separate queries and application-level joins
-         *
-         * Analysis Format:
-         *
-         * - List each error with its TypeScript error code
-         * - Identify the root cause (schema mismatch, wrong function usage, etc.)
-         * - Provide specific resolution steps
-         * - Note any schema limitations discovered
-         */
-        errorAnalysis?: string;
         /**
          * Step 1.
          *
@@ -77,16 +12,18 @@ export declare namespace IAutoBeRealizeCoderApplication {
          * function according to the Realize Coder Agent specification. Before
          * writing the actual code, think through the logic and structure.
          *
-         * The plan MUST follow MANDATORY SCHEMA-FIRST APPROACH:
+         * The plan follows a SCHEMA-FIRST APPROACH:
          *
-         * 📋 STEP 1 - PRISMA SCHEMA VERIFICATION (MOST CRITICAL):
+         * 📋 STEP 1 - PRISMA SCHEMA VERIFICATION:
          *
-         * - EXAMINE the actual Prisma schema model definition
-         * - LIST EVERY field that exists in the model with exact types
-         * - EXPLICITLY NOTE fields that DO NOT exist (e.g., "Note: deleted_at field
-         *   DOES NOT EXIST")
-         * - Common assumption errors to avoid: `deleted_at`, `created_by`,
-         *   `updated_by`, `is_deleted`, `is_active`
+         * DO:
+         * - Examine the actual Prisma schema model definition
+         * - List EVERY field that exists in the model with exact types
+         * - Explicitly note fields that DO NOT exist
+         *
+         * DO NOT:
+         * - Assume common fields exist without verification
+         * - Use fields like deleted_at, created_by, updated_by, is_deleted, is_active without checking
          *
          * 📋 STEP 2 - FIELD INVENTORY:
          *
@@ -220,8 +157,9 @@ export declare namespace IAutoBeRealizeCoderApplication {
          * Draft WITHOUT using native Date type.
          *
          * This is the initial drafting phase where you outline the basic skeleton
-         * of the function. CRITICAL: This draft must NEVER use the native Date
-         * type.
+         * of the function.
+         *
+         * DO NOT: Use the native Date type.
          *
          * - The function signature must correctly include `user`, `parameters`, and
          *   `body` arguments.
@@ -230,13 +168,13 @@ export declare namespace IAutoBeRealizeCoderApplication {
          * - Mark any incomplete or missing parts clearly with placeholders (e.g.,
          *   comments or temporary values).
          *
-         * ⚠️ Import rules:
+         * Import rules:
          *
-         * - Do NOT add any new import statements manually.
-         * - All necessary imports are provided globally or by the system
-         *   automatically.
-         * - Writing import statements directly is prohibited and may cause compile
-         *   errors. If import errors occur, check your environment configuration.
+         * DO NOT:
+         * - Add any new import statements manually
+         * - Write import statements directly (this causes compile errors)
+         *
+         * Note: All necessary imports are provided globally or by the system automatically.
          *
          * ✅ Requirements:
          *
@@ -338,8 +276,4 @@ export declare namespace IAutoBeRealizeCoderApplication {
          */
         implementationCode: string;
     }
-    interface IPipeOutput {
-        result: RealizeCoderOutput | FAILED;
-        operation: AutoBeOpenApi.IOperation;
-    }
 }

package/lib/agent/src/orchestrate/realize/structures/IAutoBeRealizeWriteApplication.js

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

package/lib/agent/src/orchestrate/realize/structures/IAutoBeRealizeWriteApplication.js.map

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

package/lib/agent/src/orchestrate/realize/utils/AuthorizationFileSystem.d.ts

@@ -0,0 +1,5 @@
+export declare namespace AuthorizationFileSystem {
+    const decoratorPath: (name: string) => string;
+    const payloadPath: (name: string) => string;
+    const providerPath: (name: string) => string;
+}

package/lib/agent/src/orchestrate/realize/utils/AuthorizationFileSystem.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"AuthorizationFileSystem.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/realize/utils/AuthorizationFileSystem.ts"],"names":[],"mappings":";;;AAAA,IAAiB,uBAAuB,CASvC;AATD,WAAiB,uBAAuB;IACzB,qCAAa,GAAG,CAAC,IAAY,EAAU,EAAE,CACpD,kBAAkB,IAAI,KAAK,CAAC;IAEjB,mCAAW,GAAG,CAAC,IAAY,EAAU,EAAE,CAClD,0BAA0B,IAAI,KAAK,CAAC;IAEzB,oCAAY,GAAG,CAAC,IAAY,EAAU,EAAE,CACnD,2BAA2B,IAAI,KAAK,CAAC;AACzC,CAAC,EATgB,uBAAuB,uCAAvB,uBAAuB,QASvC"}

package/lib/agent/src/orchestrate/realize/utils/AutoBeRealizeAuthorizationFileSystem.d.ts

@@ -0,0 +1,5 @@
+export declare namespace AutoBeRealizeAuthorizationFileSystem {
+    const getDecoratorPath: (name: string) => string;
+    const getPayloadPath: (name: string) => string;
+    const getProviderPath: (name: string) => string;
+}

package/lib/agent/src/orchestrate/realize/utils/AutoBeRealizeAuthorizationFileSystem.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"AutoBeRealizeAuthorizationFileSystem.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/realize/utils/AutoBeRealizeAuthorizationFileSystem.ts"],"names":[],"mappings":";;;AAAA,IAAiB,oCAAoC,CAQpD;AARD,WAAiB,oCAAoC;IACtC,qDAAgB,GAAG,CAAC,IAAY,EAAE,EAAE,CAAC,kBAAkB,IAAI,KAAK,CAAC;IAEjE,mDAAc,GAAG,CAAC,IAAY,EAAE,EAAE,CAC7C,0BAA0B,IAAI,KAAK,CAAC;IAEzB,oDAAe,GAAG,CAAC,IAAY,EAAE,EAAE,CAC9C,2BAA2B,IAAI,KAAK,CAAC;AACzC,CAAC,EARgB,oCAAoC,oDAApC,oCAAoC,QAQpD"}

package/lib/agent/src/orchestrate/realize/utils/AutoBeRealizeAuthorizationReplaceImport.d.ts

@@ -0,0 +1,4 @@
+export declare namespace AutoBeRealizeAuthorizationReplaceImport {
+    function replaceProviderImport(role: string, content: string): string;
+    function replaceDecoratorImport(role: string, content: string): string;
+}

package/lib/agent/src/orchestrate/realize/utils/AutoBeRealizeAuthorizationReplaceImport.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"AutoBeRealizeAuthorizationReplaceImport.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/realize/utils/AutoBeRealizeAuthorizationReplaceImport.ts"],"names":[],"mappings":";;;AAAA,IAAiB,uCAAuC,CA+DvD;AA/DD,WAAiB,uCAAuC;IACtD,SAAgB,qBAAqB,CAAC,IAAY,EAAE,OAAe;QACjE,IAAI,cAAc,GAAG,OAAO,CAAC;QAE7B,MAAM,eAAe,GACnB,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,CAAC;QAE7D,MAAM,mBAAmB,GACvB,qDAAqD,CAAC;QACxD,MAAM,uBAAuB,GAC3B,6EAA6E,CAAC;QAEhF,MAAM,eAAe,GAAG,4CAA4C,CAAC;QACrE,MAAM,mBAAmB,GAAG,4CAA4C,CAAC;QAEzE,MAAM,mBAAmB,GACvB,gDAAgD,CAAC;QACnD,MAAM,uBAAuB,GAC3B,gDAAgD,CAAC;QAEnD,MAAM,cAAc,GAAG,8CAA8C,CAAC;QACtE,MAAM,kBAAkB,GAAG,YAAY,eAAe,4CAA4C,eAAe,WAAW,CAAC;QAE7H,iBAAiB;QACjB,cAAc,GAAG,cAAc,CAAC,OAAO,CACrC,mBAAmB,EACnB,uBAAuB,CACxB,CAAC;QACF,cAAc,GAAG,cAAc,CAAC,OAAO,CACrC,eAAe,EACf,mBAAmB,CACpB,CAAC;QACF,cAAc,GAAG,cAAc,CAAC,OAAO,CACrC,mBAAmB,EACnB,uBAAuB,CACxB,CAAC;QACF,cAAc,GAAG,cAAc,CAAC,OAAO,CAAC,cAAc,EAAE,kBAAkB,CAAC,CAAC;QAE5E,OAAO,cAAc,CAAC;IACxB,CAAC;IAtCe,6DAAqB,wBAsCpC,CAAA;IAED,SAAgB,sBAAsB,CACpC,IAAY,EACZ,OAAe;QAEf,IAAI,cAAc,GAAG,OAAO,CAAC;QAE7B,MAAM,aAAa,GAAG,IAAI,CAAC,WAAW,EAAE,CAAC;QAEzC,+CAA+C;QAC/C,MAAM,gBAAgB,GAAG,gDAAgD,CAAC;QAE1E,iCAAiC;QACjC,MAAM,oBAAoB,GAAG,YAAY,aAAa,4CAA4C,aAAa,aAAa,CAAC;QAE7H,QAAQ;QACR,cAAc,GAAG,cAAc,CAAC,OAAO,CACrC,gBAAgB,EAChB,oBAAoB,CACrB,CAAC;QAEF,OAAO,cAAc,CAAC;IACxB,CAAC;IArBe,8DAAsB,yBAqBrC,CAAA;AACH,CAAC,EA/DgB,uCAAuC,uDAAvC,uCAAuC,QA+DvD"}

package/lib/agent/src/orchestrate/realize/utils/InternalFileSystem.d.ts

@@ -0,0 +1,8 @@
+export declare namespace InternalFileSystem {
+    /**
+     * Get template files for all of realize agents
+     *
+     * @returns Template file paths
+     */
+    const DEFAULT: string[];
+}

package/lib/agent/src/orchestrate/realize/utils/InternalFileSystem.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"InternalFileSystem.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/realize/utils/InternalFileSystem.ts"],"names":[],"mappings":";;;AAAA,IAAiB,kBAAkB,CAWlC;AAXD,WAAiB,kBAAkB;IACjC;;;;OAIG;IACU,0BAAO,GAAG;QACrB,yCAAyC;QACzC,iBAAiB;QACjB,6BAA6B;KAC9B,CAAC;AACJ,CAAC,EAXgB,kBAAkB,kCAAlB,kBAAkB,QAWlC"}

package/lib/agent/src/orchestrate/realize/utils/ProviderFileSystem.d.ts

@@ -0,0 +1,3 @@
+export declare namespace RealizeFileSystem {
+    const providerPath: (filename: string) => string;
+}

package/lib/agent/src/orchestrate/realize/utils/ProviderFileSystem.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"ProviderFileSystem.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/realize/utils/ProviderFileSystem.ts"],"names":[],"mappings":";;;AAAA,IAAiB,iBAAiB,CAGjC;AAHD,WAAiB,iBAAiB;IACnB,8BAAY,GAAG,CAAC,QAAgB,EAAU,EAAE,CACvD,iBAAiB,QAAQ,KAAK,CAAC;AACnC,CAAC,EAHgB,iBAAiB,iCAAjB,iBAAiB,QAGjC"}

package/lib/agent/src/orchestrate/realize/utils/replaceImportStatements.d.ts

@@ -0,0 +1,4 @@
+import { ILlmSchema } from "@samchon/openapi";
+import { AutoBeContext } from "../../../context/AutoBeContext";
+import { IAutoBeTestScenarioArtifacts } from "../../test/structures/IAutoBeTestScenarioArtifacts";
+export declare function replaceImportStatements<Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>): (artifacts: IAutoBeTestScenarioArtifacts, code: string, decoratorType?: string) => Promise<string>;

package/lib/{orchestrate → agent/src/orchestrate}/realize/utils/replaceImportStatements.js

@@ -25,7 +25,10 @@ function replaceImportStatements(ctx) {
                 .replace(/import\s+typia\s*from\s*["']typia["']\s*;?\s*/gm, "")
                 .replace(/import\s*{\s*Prisma\s*}\s*from\s*["']@prisma\/client["']\s*;?\s*/gm, "")
                 .replace(/import\s*{\s*v4\s*}\s*from\s*["']uuid["']\s*;?\s*/gm, "")
-                .replace(/import\s*{\s*toISOStringSafe\s*}\s*from\s*["']\.\.\/util\/toISOStringSafe["']\s*;?\s*/gm, "");
+                .replace(/import\s*{\s*toISOStringSafe\s*}\s*from\s*["']\.\.\/util\/toISOStringSafe["']\s*;?\s*/gm, "")
+                // Remove JWT import if it exists (to prevent duplication)
+                .replace(/import\s+jwt\s+from\s*["']jsonwebtoken["']\s*;?\s*/gm, "")
+                .replace(/import\s*\*\s*as\s+jwt\s+from\s*["']jsonwebtoken["']\s*;?\s*/gm, "");
             // Remove any existing API structure imports
             // Pattern 1: ../api/structures path
             code = code.replace(/import\s*(?:type\s*)?{\s*[^}]+\s*}\s*from\s*["']\.\.\/api\/structures\/[^"']+["']\s*;?\s*/gm, "");
@@ -44,6 +47,7 @@ function replaceImportStatements(ctx) {
             }
             // Build the standard imports
             const imports = [
+                'import jwt from "jsonwebtoken";',
                 'import { MyGlobal } from "../MyGlobal";',
                 'import typia, { tags } from "typia";',
                 'import { Prisma } from "@prisma/client";',
@@ -71,6 +75,7 @@ function replaceImportStatements(ctx) {
             code = code.replace(/\\n/g, "\n").replace(/\\"/g, '"').replace(/\\'/g, "'");
             // Apply final beautification
             code = yield compiler.typescript.beautify(code);
+            code = code.replaceAll("typia.tags.assert", "typia.assert");
             return code;
         });
     };

package/lib/agent/src/orchestrate/realize/utils/replaceImportStatements.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"replaceImportStatements.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/realize/utils/replaceImportStatements.ts"],"names":[],"mappings":";;;;;;;;;;;AAMA,0DA8HC;AA9HD,SAAgB,uBAAuB,CACrC,GAAyB;IAEzB,OAAO,UACL,SAAuC,EACvC,IAAY,EACZ,aAAsB;;YAEtB,MAAM,cAAc,GAAa,KAAK,CAAC,IAAI,CACzC,IAAI,GAAG,CACL,MAAM,CAAC,IAAI,CAAC,SAAS,CAAC,QAAQ,CAAC,UAAU,CAAC,OAAO,CAAC,CAAC,GAAG,CACpD,CAAC,GAAG,EAAE,EAAE,CAAC,GAAG,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,CAAE,CAC5B,CACF,CACF,CAAC;YAEF,MAAM,QAAQ,GAAoB,MAAM,GAAG,CAAC,QAAQ,EAAE,CAAC;YACvD,IAAI,GAAG,MAAM,QAAQ,CAAC,UAAU,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC;YAChD,kEAAkE;YAClE,IAAI,GAAG,IAAI;iBACR,OAAO,CACN,qEAAqE,EACrE,EAAE,CACH;iBACA,OAAO,CACN,oEAAoE,EACpE,EAAE,CACH;iBACA,OAAO,CAAC,wDAAwD,EAAE,EAAE,CAAC;iBACrE,OAAO,CACN,oEAAoE,EACpE,EAAE,CACH;iBACA,OAAO,CAAC,iDAAiD,EAAE,EAAE,CAAC;iBAC9D,OAAO,CACN,oEAAoE,EACpE,EAAE,CACH;iBACA,OAAO,CAAC,qDAAqD,EAAE,EAAE,CAAC;iBAClE,OAAO,CACN,yFAAyF,EACzF,EAAE,CACH;gBACD,0DAA0D;iBACzD,OAAO,CAAC,sDAAsD,EAAE,EAAE,CAAC;iBACnE,OAAO,CACN,gEAAgE,EAChE,EAAE,CACH,CAAC;YAEJ,4CAA4C;YAC5C,oCAAoC;YACpC,IAAI,GAAG,IAAI,CAAC,OAAO,CACjB,6FAA6F,EAC7F,EAAE,CACH,CAAC;YACF,2DAA2D;YAC3D,IAAI,GAAG,IAAI,CAAC,OAAO,CACjB,mHAAmH,EACnH,EAAE,CACH,CAAC;YAEF,6DAA6D;YAC7D,KAAK,MAAM,GAAG,IAAI,cAAc,EAAE,CAAC;gBACjC,wDAAwD;gBACxD,MAAM,eAAe,GAAG,IAAI,MAAM,CAChC,+BAA+B,GAAG,2CAA2C,EAC7E,IAAI,CACL,CAAC;gBACF,IAAI,GAAG,IAAI,CAAC,OAAO,CAAC,eAAe,EAAE,EAAE,CAAC,CAAC;YAC3C,CAAC;YAED,yEAAyE;YACzE,IAAI,aAAa,EAAE,CAAC;gBAClB,MAAM,kBAAkB,GAAG,IAAI,MAAM,CACnC,+BAA+B,aAAa,qDAAqD,aAAa,gBAAgB,EAC9H,IAAI,CACL,CAAC;gBACF,IAAI,GAAG,IAAI,CAAC,OAAO,CAAC,kBAAkB,EAAE,EAAE,CAAC,CAAC;YAC9C,CAAC;YAED,6BAA6B;YAC7B,MAAM,OAAO,GAAG;gBACd,iCAAiC;gBACjC,yCAAyC;gBACzC,sCAAsC;gBACtC,0CAA0C;gBAC1C,4BAA4B;gBAC5B,2DAA2D;gBAC3D,GAAG,cAAc,CAAC,GAAG,CACnB,CAAC,GAAG,EAAE,EAAE,CACN,YAAY,GAAG,qDAAqD,GAAG,IAAI,CAC9E;aACF,CAAC;YAEF,6CAA6C;YAC7C,IAAI,aAAa,EAAE,CAAC;gBAClB,OAAO,CAAC,IAAI,CACV,YAAY,aAAa,kCAAkC,aAAa,GAAG,CAC5E,CAAC;YACJ,CAAC;YAED,IAAI,GAAG,CAAC,GAAG,OAAO,EAAE,EAAE,EAAE,IAAI,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;YAEzC,6BAA6B;YAC7B,IAAI;gBACF,IAAI;oBACF,oCAAoC;qBACnC,OAAO,CAAC,SAAS,EAAE,EAAE,CAAC;oBACvB,0DAA0D;qBACzD,OAAO,CAAC,SAAS,EAAE,MAAM,CAAC;oBAC3B,6CAA6C;qBAC5C,OAAO,CAAC,uCAAuC,EAAE,UAAU,CAAC;oBAC7D,0CAA0C;qBACzC,IAAI,EAAE,GAAG,IAAI,CAAC;YAEnB,oBAAoB;YACpB,IAAI,GAAG,IAAI,CAAC,OAAO,CAAC,MAAM,EAAE,IAAI,CAAC,CAAC,OAAO,CAAC,MAAM,EAAE,GAAG,CAAC,CAAC,OAAO,CAAC,MAAM,EAAE,GAAG,CAAC,CAAC;YAE5E,6BAA6B;YAC7B,IAAI,GAAG,MAAM,QAAQ,CAAC,UAAU,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC;YAEhD,IAAI,GAAG,IAAI,CAAC,UAAU,CAAC,mBAAmB,EAAE,cAAc,CAAC,CAAC;YAE5D,OAAO,IAAI,CAAC;QACd,CAAC;KAAA,CAAC;AACJ,CAAC"}

package/lib/agent/src/orchestrate/test/compile/completeTestCode.d.ts

@@ -0,0 +1,2 @@
+import { IAutoBeTestScenarioArtifacts } from "../structures/IAutoBeTestScenarioArtifacts";
+export declare function completeTestCode(artifacts: IAutoBeTestScenarioArtifacts, code: string): string;

package/lib/agent/src/orchestrate/test/compile/completeTestCode.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"completeTestCode.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/test/compile/completeTestCode.ts"],"names":[],"mappings":";;AAEA,4CAgCC;AAhCD,SAAgB,gBAAgB,CAC9B,SAAuC,EACvC,IAAY;IAEZ,MAAM,cAAc,GAAa,KAAK,CAAC,IAAI,CACzC,IAAI,GAAG,CACL,MAAM,CAAC,IAAI,CAAC,SAAS,CAAC,QAAQ,CAAC,UAAU,CAAC,OAAO,CAAC,CAAC,GAAG,CACpD,CAAC,GAAG,EAAE,EAAE,CAAC,GAAG,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,CAAE,CAC5B,CACF,CACF,CAAC;IAEF,IAAI,GAAG,IAAI,CAAC,OAAO,CAAC,mCAAmC,EAAE,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC;IACpE,IAAI,GAAG,IAAI,CAAC,OAAO,CAAC,mCAAmC,EAAE,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC;IACpE,IAAI,GAAG,IAAI,CAAC,UAAU,CACpB,yBAAyB,EACzB,8BAA8B,CAC/B,CAAC;IACF,IAAI,GAAG;QACL,0EAA0E;QAC1E,gDAAgD;QAChD,sCAAsC;QACtC,EAAE;QACF,8CAA8C;QAC9C,GAAG,cAAc,CAAC,GAAG,CACnB,CAAC,GAAG,EAAE,EAAE,CACN,iBAAiB,GAAG,qDAAqD,GAAG,IAAI,CACnF;QACD,EAAE;QACF,IAAI;KACL,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;IACb,OAAO,IAAI,CAAC;AACd,CAAC"}

package/lib/agent/src/orchestrate/test/compile/filterTestFileName.d.ts

@@ -0,0 +1 @@
+export declare function filterTestFileName(key: string): boolean;

package/lib/agent/src/orchestrate/test/compile/filterTestFileName.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"filterTestFileName.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/test/compile/filterTestFileName.ts"],"names":[],"mappings":";;AAAA,gDAQC;AARD,SAAgB,kBAAkB,CAAC,GAAW;IAC5C,IAAI,GAAG,CAAC,QAAQ,CAAC,KAAK,CAAC,KAAK,KAAK;QAAE,OAAO,KAAK,CAAC;SAC3C,IAAI,GAAG,CAAC,UAAU,CAAC,MAAM,CAAC,KAAK,IAAI;QAAE,OAAO,IAAI,CAAC;IACtD,OAAO,CACL,GAAG,CAAC,UAAU,CAAC,OAAO,CAAC,KAAK,IAAI;QAChC,GAAG,CAAC,UAAU,CAAC,gBAAgB,CAAC,KAAK,IAAI;QACzC,GAAG,CAAC,UAAU,CAAC,iBAAiB,CAAC,KAAK,KAAK,CAC5C,CAAC;AACJ,CAAC"}

package/lib/agent/src/orchestrate/test/compile/getTestExternalDeclarations.d.ts

@@ -0,0 +1,3 @@
+import { ILlmSchema } from "@samchon/openapi";
+import { AutoBeContext } from "../../../context/AutoBeContext";
+export declare function getTestExternalDeclarations<Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>): Promise<Record<string, string>>;

package/lib/agent/src/orchestrate/test/compile/getTestExternalDeclarations.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"getTestExternalDeclarations.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/test/compile/getTestExternalDeclarations.ts"],"names":[],"mappings":";;;;;;;;;;;AAMA,kEAKC;AATD,+BAAiC;AAIjC,SAAsB,2BAA2B,CAE/C,GAAyB;;QACzB,MAAM,QAAQ,GAAG,MAAM,GAAG,CAAC,QAAQ,EAAE,CAAC;QACtC,OAAO,SAAS,CAAC,GAAG,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC;IACtC,CAAC;CAAA;AAED,MAAM,SAAS,GAAG,IAAI,gBAAS,CAAC,CAAO,QAA6B,EAAE,EAAE;IACtE,MAAM,OAAO,GAA2B,MAAM,QAAQ,CAAC,WAAW,EAAE,CAAC;IACrE,MAAM,QAAQ,GAAG,CAAC,QAAgB,EAA0B,EAAE;QAC5D,MAAM,OAAO,GAAuB,OAAO,CAAC,QAAQ,CAAC,CAAC;QACtD,IAAI,OAAO,KAAK,SAAS;YAAE,MAAM,IAAI,KAAK,CAAC,mBAAmB,QAAQ,EAAE,CAAC,CAAC;QAC1E,OAAO,EAAE,CAAC,QAAQ,CAAC,EAAE,OAAO,EAAE,CAAC;IACjC,CAAC,CAAC;IACF,OAAO,gCACF,QAAQ,CAAC,iDAAiD,CAAC,GAC3D,QAAQ,CAAC,mDAAmD,CAAC,CAChC,CAAC;AACrC,CAAC,CAAA,CAAC,CAAC"}

package/lib/agent/src/orchestrate/test/compile/getTestScenarioArtifacts.d.ts

@@ -0,0 +1,5 @@
+import { AutoBeTestScenario } from "@autobe/interface";
+import { ILlmSchema } from "@samchon/openapi";
+import { AutoBeContext } from "../../../context/AutoBeContext";
+import { IAutoBeTestScenarioArtifacts } from "../structures/IAutoBeTestScenarioArtifacts";
+export declare function getTestScenarioArtifacts<Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, scenario: Pick<AutoBeTestScenario, "endpoint" | "dependencies">): Promise<IAutoBeTestScenarioArtifacts>;

package/lib/agent/src/orchestrate/test/compile/getTestScenarioArtifacts.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"getTestScenarioArtifacts.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/test/compile/getTestScenarioArtifacts.ts"],"names":[],"mappings":";;;;;;;;;;;AAUA,4DA4BC;AAjCD,8CAAkE;AAKlE,SAAsB,wBAAwB,CAC5C,GAAyB,EACzB,QAA+D;;QAE/D,MAAM,QAAQ,GAAoB,MAAM,GAAG,CAAC,QAAQ,EAAE,CAAC;QACvD,MAAM,QAAQ,GAA4B,cAAc,CACtD,QAAQ,EACR,GAAG,CAAC,KAAK,EAAE,CAAC,SAAU,CAAC,QAAQ,CAChC,CAAC;QACF,MAAM,OAAO,GAAuB,MAAM,CAAC,OAAO,CAChD,MAAM,QAAQ,CAAC,SAAS,CAAC,KAAK,CAAC,QAAQ,CAAC,CACzC,CAAC;QACF,MAAM,MAAM,GAAG,CAAC,MAAc,EAAE,OAAgB,EAAE,EAAE;YAClD,MAAM,MAAM,GAAuB,OAAO,CAAC,MAAM,CAC/C,CAAC,CAAC,GAAG,CAAC,EAAE,EAAE,CAAC,GAAG,CAAC,UAAU,CAAC,MAAM,CAAC,KAAK,IAAI,CAC3C,CAAC;YACF,OAAO,MAAM,CAAC,WAAW,CACvB,OAAO;gBACL,CAAC,CAAC,MAAM,CAAC,MAAM,CAAC,CAAC,CAAC,GAAG,CAAC,EAAE,EAAE,CAAC,GAAG,CAAC,UAAU,CAAC,OAAO,CAAC,KAAK,KAAK,CAAC;gBAC7D,CAAC,CAAC,MAAM,CACX,CAAC;QACJ,CAAC,CAAC;QACF,OAAO;YACL,QAAQ;YACR,GAAG,EAAE,MAAM,CAAC,SAAS,EAAE,oBAAoB,CAAC;YAC5C,GAAG,EAAE,MAAM,CAAC,oBAAoB,CAAC;YACjC,GAAG,EAAE,MAAM,CAAC,eAAe,CAAC;SAC7B,CAAC;IACJ,CAAC;CAAA;AAED,SAAS,cAAc,CACrB,QAA+D,EAC/D,QAAiC;IAEjC,MAAM,UAAU,GAA+B,QAAQ,CAAC,UAAU,CAAC,MAAM,CACvE,CAAC,EAAE,EAAE,EAAE,CACL,CAAC,QAAQ,CAAC,QAAQ,CAAC,MAAM,KAAK,EAAE,CAAC,MAAM;QACrC,QAAQ,CAAC,QAAQ,CAAC,IAAI,KAAK,EAAE,CAAC,IAAI,CAAC;QACrC,QAAQ,CAAC,YAAY,CAAC,IAAI,CACxB,CAAC,EAAE,EAAE,EAAE,CACL,EAAE,CAAC,QAAQ,CAAC,MAAM,KAAK,EAAE,CAAC,MAAM,IAAI,EAAE,CAAC,QAAQ,CAAC,IAAI,KAAK,EAAE,CAAC,IAAI,CACnE,CACJ,CAAC;IACF,MAAM,UAAU,GAA8B;QAC5C,aAAa,EAAE,QAAQ,CAAC,UAAU,CAAC,aAAa;QAChD,OAAO,EAAE,EAAE;KACZ,CAAC;IACF,MAAM,KAAK,GAAG,CAAC,QAAgB,EAAE,EAAE;QACjC,4BAAkB,CAAC,KAAK,CAAC;YACvB,UAAU,EAAE,QAAQ,CAAC,UAAU;YAC/B,MAAM,EAAE,EAAE,IAAI,EAAE,wBAAwB,QAAQ,EAAE,EAAE;YACpD,OAAO,EAAE,CAAC,CAAC,EAAE,EAAE;gBACb,IAAI,4BAAkB,CAAC,WAAW,CAAC,CAAC,CAAC,EAAE,CAAC;oBACtC,MAAM,GAAG,GAAW,CAAC,CAAC,IAAI,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,GAAG,EAAG,CAAC;oBAC7C,UAAU,CAAC,OAAO,CAAC,GAAG,CAAC,GAAG,QAAQ,CAAC,UAAU,CAAC,OAAO,CAAC,GAAG,CAAC,CAAC;gBAC7D,CAAC;YACH,CAAC;SACF,CAAC,CAAC;IACL,CAAC,CAAC;IACF,KAAK,MAAM,EAAE,IAAI,UAAU,EAAE,CAAC;QAC5B,IAAI,EAAE,CAAC,WAAW;YAAE,KAAK,CAAC,EAAE,CAAC,WAAW,CAAC,QAAQ,CAAC,CAAC;QACnD,IAAI,EAAE,CAAC,YAAY;YAAE,KAAK,CAAC,EAAE,CAAC,YAAY,CAAC,QAAQ,CAAC,CAAC;IACvD,CAAC;IACD,OAAO;QACL,UAAU;QACV,UAAU;KACX,CAAC;AACJ,CAAC"}

package/lib/{orchestrate/test → agent/src/orchestrate/test/histories}/transformTestCorrectHistories.d.ts

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

package/lib/agent/src/orchestrate/test/histories/transformTestCorrectHistories.js

@@ -0,0 +1,34 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.transformTestCorrectHistories = void 0;
+const uuid_1 = require("uuid");
+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\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the test corrections directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\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/agent/src/orchestrate/test/histories/transformTestCorrectHistories.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"transformTestCorrectHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/test/histories/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,okxBAAwC,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 → agent/src/orchestrate/test/histories}/transformTestHistories.d.ts

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

package/lib/agent/src/orchestrate/test/histories/transformTestHistories.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"transformTestHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/test/histories/transformTestHistories.ts"],"names":[],"mappings":";;;AACA,+BAA0B;AAInB,MAAM,sBAAsB,GAAG,CACpC,KAAkB,EAGlB,EAAE;IACF,IAAI,KAAK,CAAC,OAAO,KAAK,IAAI;QACxB,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,4CAA4C;oBAC5C,mCAAmC;oBACnC,8CAA8C;iBAC/C,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,MAAM,KAAK,IAAI;QAC5B,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,mDAAmD;oBACnD,mCAAmC;oBACnC,qDAAqD;iBACtD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,OAAO,CAAC,IAAI,KAAK,KAAK,CAAC,MAAM,CAAC,IAAI;QAC/C,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,kDAAkD;oBAClD,sCAAsC;oBACtC,mCAAmC;oBACnC,wDAAwD;iBACzD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,MAAM,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;QAC/C,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,kDAAkD;oBAClD,sCAAsC;oBACtC,mCAAmC;oBACnC,wDAAwD;iBACzD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;IACJ,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE;gBACJ,4CAA4C;gBAC5C,mCAAmC;gBACnC,8CAA8C;aAC/C,CAAC,IAAI,CAAC,GAAG,CAAC;SACZ;KACF,CAAC;AACJ,CAAC,CAAC;AAvEW,QAAA,sBAAsB,0BAuEjC"}

package/lib/agent/src/orchestrate/test/histories/transformTestScenarioHistories.d.ts

@@ -0,0 +1,4 @@
+import { IAgenticaHistoryJson } from "@agentica/core";
+import { AutoBeOpenApi } from "@autobe/interface";
+import { AutoBeState } from "../../../context/AutoBeState";
+export declare const transformTestScenarioHistories: (state: AutoBeState, entire: AutoBeOpenApi.IOperation[], include: AutoBeOpenApi.IOperation[], exclude: Pick<AutoBeOpenApi.IOperation, "method" | "path">[]) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;

package/lib/agent/src/orchestrate/test/histories/transformTestScenarioHistories.js

@@ -0,0 +1,101 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.transformTestScenarioHistories = void 0;
+const utils_1 = require("@autobe/utils");
+const uuid_1 = require("uuid");
+const transformTestScenarioHistories = (state, entire, include, exclude) => {
+    var _a, _b;
+    const authorizations = (_b = (_a = state.interface) === null || _a === void 0 ? void 0 : _a.authorizations) !== null && _b !== void 0 ? _b : [];
+    const authorizationRoles = new Map();
+    for (const authorization of authorizations) {
+        for (const op of authorization.operations) {
+            if (op.authorizationType === null)
+                continue;
+            const value = utils_1.MapUtil.take(authorizationRoles, authorization.role, () => ({
+                name: authorization.role,
+                join: null,
+                login: null,
+            }));
+            if (op.authorizationType === "join")
+                value.join = op;
+            else if (op.authorizationType === "login")
+                value.login = op;
+        }
+    }
+    return [
+        {
+            id: (0, uuid_1.v4)(),
+            created_at: new Date().toISOString(),
+            type: "systemMessage",
+            text: "# API Test Scenario Generator AI Agent System Prompt\n\n## Naming Conventions\n\n### Notation Types\nThe following naming conventions (notations) are used throughout the system:\n- **camelCase**: First word lowercase, subsequent words capitalized (e.g., `userAccount`, `productItem`)\n- **PascalCase**: All words capitalized (e.g., `UserAccount`, `ProductItem`)\n- **snake_case**: All lowercase with underscores between words (e.g., `user_account`, `product_item`)\n\n### Specific Property Notations\n- **IAutoBeTestScenarioApplication.IScenario.functionName**: Use snake_case notation with `test_api_` prefix (format: `test_api_{core_feature}_{specific_scenario}`)\n\n## 1. Overview\n\nYou are a specialized AI Agent for generating comprehensive API test scenarios based on provided API operation definitions. Your core mission is to analyze API endpoints and create realistic, business-logic-focused test scenario drafts that will later be used by developers to implement actual E2E test functions.\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the test scenarios directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\nYou will receive an array of API operation objects along with their specifications, descriptions, and parameters. Based on these materials, you must generate structured test scenario groups that encompass both success and failure cases, considering real-world business constraints and user workflows.\n\nYour role is **scenario planning**. You must think like a QA engineer who understands business logic and user journeys, creating comprehensive test plans that cover edge cases, validation rules, and complex multi-step processes.\n\nThe final deliverable must be a structured output containing scenario groups with detailed test drafts, dependency mappings, and clear function naming that reflects user-centric perspectives.\n\n## 2. Input Material Composition\n\n### 2.1. API Operations Array\n\n* Complete API operation definitions with summary, method, path, and authorizationRole\n* The `authorizationRole` property in each operation specifies the required user role for accessing that endpoint\n* Business logic descriptions and constraints embedded in summary\n\n**Deep Analysis Requirements:**\n\n* **Business Domain Understanding**: Identify the business domain (e-commerce, content management, user authentication, etc.) and understand typical user workflows\n* **Entity Relationship Discovery**: Map relationships between different entities (users, products, orders, reviews, etc.) and understand their dependencies\n* **Workflow Pattern Recognition**: Identify common patterns like CRUD operations, authentication flows, approval processes, and multi-step transactions\n* **Constraint and Validation Rule Extraction**: Extract business rules, validation constraints, uniqueness requirements, and permission-based access controls\n* **User Journey Mapping**: Understand complete user journeys that span multiple API calls and identify realistic test scenarios\n* **Authorization Analysis**: Examine the `authorizationRole` field in each operation to understand role-based access requirements\n\n### 2.2. Include/Exclude Lists\n\n* **Include List**: API endpoints that must be covered in the test scenarios being generated. These are the primary targets of the current test generation. Each included endpoint shows its endpoint and related authentication APIs.\n* **Exclude List**: Endpoints that do not require new test scenarios in this iteration. However, these endpoints may still be referenced as **dependencies** in the scenario drafts if the current tests logically depend on their outcomes or data.\n\n**Deep Analysis Requirements:**\n\n* **Dependency Identification**: Understand which excluded endpoints can serve as prerequisites for included endpoints\n* **Coverage Gap Analysis**: Ensure all included endpoints have comprehensive test coverage without redundancy\n* **Cross-Reference Mapping**: Map relationships between included endpoints and available excluded endpoints for dependency planning\n* **Authentication Context Mapping**: Reference the \"Included in Test Plan\" section to understand which authentication APIs are available for each endpoint\n\n## 2.3. Authentication Rules\n\n**CRITICAL AUTHENTICATION REQUIREMENTS**: Each endpoint contains an `authorizationRole` property in the operation definition (found in the Operations section). Additionally, the \"Included in Test Plan\" section shows each endpoint with its related authentication APIs. Follow these mandatory rules:\n\n* **Authorization Role Source**: The `authorizationRole` is specified in each operation within the Operations array. If `authorizationRole` is null, the endpoint is public.\n* **Authentication API Reference**: Consult the \"Included in Test Plan\" section to see which authentication APIs (join/login) are available for each endpoint's required role.\n* **Single Role Scenarios**: When testing an operation with a specific `authorizationRole`, you MUST include the corresponding `join` operation in dependencies to create the user with that role first.\n* **Multiple Role Scenarios**: If your test scenario involves multiple actors with different roles, you MUST include both `join` and `login` operations for proper role switching between different user accounts.\n* **Public Endpoints**: If `authorizationRole` is null, no authentication is required unless the scenario logically needs it for business context.\n* **Authentication Flow Order**: Always establish authentication context before testing protected endpoints, and maintain proper sequence when switching between roles.\n\n**\uD83D\uDD25 CRITICAL: JOIN vs LOGIN Usage Rules**\n\n**`join` Operation Rules:**\n- `join` operation **AUTOMATICALLY LOGS IN** the newly created user\n- After `join`, the user context is **IMMEDIATELY** established\n- Use `join` when creating a **NEW** user account\n- Use `join` for **ALL user context switching to new users** - this is the primary method for switching to a different user\n\n**`login` Operation Rules:**\n- Use `login` **ONLY** when switching back to a **PREVIOUSLY CREATED** user account that was created earlier in the same test scenario\n- **Avoid using** `login` immediately after `join` unless specifically required by the test scenario\n- Use `login` when you need to switch back to a previously created user\n\n**When `login` after `join` might be needed:**\n- Testing login functionality specifically after account creation\n- Scenarios that explicitly test the login flow after registration\n- Business workflows that require explicit re-authentication\n\n\n**When `login` is Actually Needed:**\n- **Switching back to previously created users**: When you need to return to a user that was created earlier in the test scenario\n- **Testing login functionality specifically**: When the test scenario explicitly focuses on testing the login operation itself\n- **Explicit business requirement**: When the business workflow explicitly requires re-authentication\n\n**Single Role Testing Pattern:**\n1. Execute `join` operation to create a user with the required role\n2. Execute the target API operation with that user's context\n```\nExample: Testing admin product creation\nStep 1: POST /auth/admin/join (create admin user - automatically logged in) \nStep 2: POST /admin/products (create product with admin role)\n```\n\n**Multi-Role Testing Pattern:**\n1. Execute `join` operation to create first user (Role A) - context established\n2. Execute operations with Role A context\n3. Execute `join` operation to create second user (Role B) - context switches to Role B\n4. Execute operations with Role B context\n5. **Only if needed**: Use `login` operation to switch back to Role A\n6. Continue testing with switched role context\n\n```\nExample: User ownership validation test\nStep 1: POST /auth/users/join (create user1 - context established)\nStep 2: POST /todos (user1 creates todo)\nStep 3: POST /auth/users/join (create user2 - context switches to user2)\nStep 4: DELETE /todos/{id} (user2 tries to delete user1's todo - should fail)\nStep 5: POST /auth/users/login (switch back to user1 - only now we use login)\nStep 6: GET /todos (verify todo still exists as user1)\n```\n\n**Public Endpoint Pattern:**\n- No authentication required unless the scenario involves subsequent operations that need authentication\n```\nExample: Public product browsing\nStep 1: GET /products (no auth needed)\nOptional Step 2: POST /auth/customers/join (only if scenario continues with customer actions)\n```\n\n**AUTHENTICATION SEQUENCE REQUIREMENTS:**\n- **New User Creation & Context Switch**: Use `join` only - user context is automatically established and switches to the new user\n- **Return to Previous User**: Use `login` only when switching back to a user that was created earlier in the test scenario\n- **Sequential Order**: Authentication operations must be listed in dependencies in the correct execution order\n- **Context Persistence**: Consider that user context persists until explicitly switched via another `join` or `login`\n- **Dependency Purpose**: Clearly explain the authentication sequence and reasoning in each dependency's `purpose` field\n\n## 3. Output: `IAutoBeTestScenarioApplication.IProps` Structure\n\nThe final output must strictly follow the `IAutoBeTestScenarioApplication.IProps` structure. This consists of a top-level array called `scenarioGroups`, where each group corresponds to a single, uniquely identifiable API `endpoint` (a combination of `method` and `path`). Each group contains a list of user-centric test `scenarios` that target the same endpoint.\n\n> \u26A0\uFE0F **Important:** Each `endpoint` in the `scenarioGroups` array must be **globally unique** based on its `method` + `path` combination. **You must not define the same endpoint across multiple scenario groups.** If multiple test scenarios are needed for a single endpoint, they must all be included in **one and only one** scenario group. Duplicate endpoint declarations across groups will lead to incorrect merging or misclassification of test plans and must be avoided at all costs.\n\nEach `scenario` contains a natural-language test description (`draft`), a clearly defined function name (`functionName`), and a list of prerequisite API calls (`dependencies`) needed to set up the test environment. This structured format ensures that the output can be reliably consumed for downstream automated test code generation.\n\n### 3.1. Output Example\n\n```ts\n{\n  scenarioGroups: [\n    {\n      endpoint: { method: \"post\", path: \"/products\" }, // Must be globally unique\n      scenarios: [\n        {\n          functionName: \"test_api_product_creation_duplicate_sku_error\",\n          draft:\n            \"Test product creation failure caused by attempting to create a product with a duplicate SKU. First, create a seller account authorized to create products using the seller join operation. Then, create an initial product with a specific SKU to set up the conflict condition. Finally, attempt to create another product with the same SKU and verify that the system returns a conflict error indicating SKU uniqueness violation.\",\n          dependencies: [\n            {\n              endpoint: { method: \"post\", path: \"/shopping/sellers/auth/join\" },\n              purpose:\n                \"Create a seller account with permission to create products. This establishes the required seller role authentication context automatically.\"\n            },\n            {\n              endpoint: { method: \"post\", path: \"/shopping/sellers/sales\" },\n              purpose:\n                \"Create the first product with a specific SKU to establish the conflict condition. This uses the seller's established authentication context from the join operation.\"\n            }\n          ]\n        }\n      ]\n    }\n  ]\n}\n```\n\nThis example demonstrates the correct structure for grouping multiple test scenarios under a single unique endpoint (`POST /products`). By consolidating scenarios within a single group and maintaining endpoint uniqueness across the entire output, the structure ensures consistency and prevents duplication during test plan generation.\n\n## 4. Core Scenario Generation Principles\n\n### 4.1. Business Logic Focus Principle\n\n* **Real-World Scenarios**: Generate scenarios that reflect actual user workflows and business processes\n* **End-to-End Thinking**: Consider complete user journeys that may span multiple API calls\n* **Business Rule Validation**: Include scenarios that test business constraints, validation rules, and edge cases\n* **User Perspective**: Write scenarios from the user's perspective, focusing on what users are trying to accomplish\n\n### 4.2. Comprehensive Coverage Principle\n\n* **Success Path Coverage**: Ensure all primary business functions are covered with successful execution scenarios\n* **Failure Path Coverage**: Include validation failures, permission errors, resource not found cases, and business rule violations\n* **Edge Case Identification**: Consider boundary conditions, race conditions, and unusual but valid user behaviors\n* **State Transition Testing**: Test different states of entities and valid/invalid state transitions\n\n### 4.3. Dependency Management Principle\n\n* **Prerequisite Identification**: Clearly identify all API calls that must precede the target operation (only when explicitly required)\n* **Data Setup Requirements**: Understand what data must exist before testing specific scenarios\n* **Authentication Context**: Include necessary authentication and authorization setup steps following the detailed authentication patterns\n* **Logical Ordering**: Ensure dependencies are listed in the correct execution order, especially for authentication sequences\n\n> \u26A0\uFE0F **Note**: The `dependencies` field in a scenario is not a sequential execution plan. It is an indicative reference to other endpoints that this scenario relies on for logical or data setup context. However, for authentication flows, execution order is critical and must be clearly described in the `purpose` field of each dependency.\n\n### 4.4. Realistic Scenario Principle\n\n* **Authentic User Stories**: Create scenarios that represent real user needs and workflows\n* **Business Context Integration**: Embed scenarios within realistic business contexts (e.g., e-commerce purchase flows, content publication workflows)\n* **Multi-Step Process Modeling**: Model complex business processes that require multiple coordinated API calls\n* **Error Recovery Scenarios**: Include scenarios for how users recover from errors or complete alternative workflows\n\n### 4.5. Clear Communication Principle\n\n* **Descriptive Draft Writing**: Write clear, detailed scenario descriptions that developers can easily understand and implement\n* **Function Naming Clarity**: Create function names that immediately convey the user scenario being tested\n* **Dependency Purpose Explanation**: Clearly explain why each dependency is necessary, with special attention to authentication sequence and role requirements\n* **Business Justification**: Explain the business value and importance of each test scenario\n\n## 5. Detailed Scenario Generation Guidelines\n\n### 5.1. API Analysis Methodology\n\n* **Domain Context Discovery**: Identify the business domain and understand typical user workflows within that domain\n* **Entity Relationship Mapping**: Map relationships between different entities and understand their lifecycle dependencies\n* **Permission Model Understanding**: Analyze the `authorizationRole` field in each operation and understand user roles, permissions, and access control patterns\n* **Business Process Identification**: Identify multi-step business processes that span multiple API endpoints\n* **Validation Rule Extraction**: Extract all validation rules, constraints, and business logic from API specifications\n* **Authentication Requirements Analysis**: Review both the Operations array for `authorizationRole` and the \"Included in Test Plan\" section for available authentication APIs\n\n### 5.2. Scenario Draft Structure\n\nEach scenario draft should include:\n\n* **Context Setting**: Brief explanation of the business context and user motivation\n* **Authentication Setup**: Clear description of required authentication steps and role establishment\n* **Step-by-Step Process**: Detailed description of the testing process, including all necessary steps with proper authentication context\n* **Expected Outcomes**: Clear description of what should happen in both success and failure cases\n* **Business Rule Validation**: Specific business rules or constraints being tested\n* **Data Requirements**: What data needs to be prepared or validated during testing\n\n### 5.3. Function Naming Guidelines\n\nFollow the business feature-centric naming convention:\n\n* **Prefix**: Must start with `test_api_`\n* **Core Feature**: Primary business feature or entity being tested (customer, seller, cart, push_message, etc.)\n* **Specific Scenario**: Specific operation or scenario context (join_verification_not_found, login_success, etc.)\n\n**Pattern**: `test_api_[core_feature]_[specific_scenario]`\n\n**Examples:**\n\n* `test_api_customer_join_verification_not_found`\n* `test_api_seller_login_success`\n* `test_api_cart_discountable_ticket_duplicated`\n* `test_api_product_review_update`\n\n### 5.4. Dependency Identification Process\n\n* **Prerequisite Data Creation**: Identify what entities must be created before testing the target endpoint\n* **Authentication Setup**: Determine necessary authentication and authorization steps based on `authorizationRole` and available authentication APIs\n* **State Preparation**: Understand what system state must be established before testing\n* **Resource Relationship**: Map relationships between resources and identify dependent resource creation\n* **Role-Based Dependencies**: Ensure proper authentication context is established for each required role\n\n### 5.5. Multi-Scenario Planning\n\nFor complex endpoints, generate multiple scenarios covering:\n\n* **Happy Path**: Successful execution with valid data and proper authentication\n* **Validation Errors**: Various types of input validation failures\n* **Permission Errors**: Unauthorized access attempts and role-based access violations\n* **Resource State Errors**: Operations on resources in invalid states\n* **Business Rule Violations**: Attempts to violate domain-specific business rules\n* **Authentication Errors**: Invalid authentication attempts, expired sessions, role mismatches\n\n## 6. Dependency Purpose Guidelines\n\n* **The `dependencies` array refers to relevant API calls this scenario logically depends on, whether or not they are in the include list.**\n* **The presence of a dependency does not imply that it must be executed immediately beforehand, except for authentication sequences where order is critical.**\n* **Execution order, especially for authentication flows, should be explicitly explained in the `purpose`.**\n* **Authentication dependencies must clearly indicate the role being established and the sequence requirement.**\n\nExample:\n\n```yaml\ndependencies:\n  - endpoint: { method: \"post\", path: \"/sellers/auth/join\" }\n    purpose: \"Create a seller account to establish seller role authentication context. This must be executed first before any seller operations.\"\n  - endpoint: { method: \"post\", path: \"/posts\" }\n    purpose: \"Create a post using the seller's authentication context and extract postId for use in voting scenario. This must be done after seller authentication.\"\n```\n\n## 7. Error Scenario Guidelines\n\n### 7.1. Purpose and Importance of Error Scenarios\n\nTest scenarios must cover not only successful business flows but also various error conditions to ensure robust system behavior. Error scenarios help verify that appropriate responses are returned for invalid inputs, unauthorized access, resource conflicts, and business rule violations.\n\n### 7.2. Error Scenario Categories\n\n* **Validation Errors**: Invalid input data, missing required fields, format violations\n* **Authentication/Authorization Errors**: Unauthorized access, insufficient permissions, expired sessions, wrong role access attempts\n* **Resource State Errors**: Operations on non-existent resources, invalid state transitions\n* **Business Rule Violations**: Attempts to violate domain-specific constraints and rules\n* **System Constraint Violations**: Duplicate resource creation, referential integrity violations\n\n### 7.3. Error Scenario Writing Guidelines\n\n* **Specific Error Conditions**: Clearly define the error condition being tested\n* **Expected Error Response**: Specify what type of error response should be returned\n* **Realistic Error Situations**: Model error conditions that actually occur in real usage\n* **Recovery Scenarios**: Consider how users might recover from or handle error conditions\n* **Authentication-Related Errors**: Include scenarios for role mismatches, unauthorized access, and authentication failures\n\n### 7.4. Error Scenario Example\n\n```ts\n// scenarioGroups.scenarios[*]\n{\n  draft: \"Test product creation failure caused by attempting to create a product with a duplicate SKU. First, create a seller account authorized to create products using the seller join operation to establish proper authentication context. Then, create an initial product with a specific SKU to set up the conflict condition. Finally, attempt to create another product with the same SKU using the same seller's authentication context and verify that the system returns a conflict error indicating SKU uniqueness violation. Note that these steps must be executed in order to properly simulate the scenario.\",\n  functionName: \"test_api_product_creation_duplicate_sku_error\",\n  dependencies: [\n    {\n      endpoint: { method: \"post\", path: \"/shopping/sellers/auth/join\" },\n      purpose: \"Create a seller account with permission to create products. This must be done first to establish the required seller role authentication context before any product operations.\"\n    },\n    {\n      endpoint: { method: \"post\", path: \"/shopping/sellers/sales\" },\n      purpose: \"Create the first product with a specific SKU to establish the conflict condition. This must be done after seller creation and uses the seller's established authentication context.\"\n    }\n  ]\n}\n```\n\n**Additional Notes:**\n\n* It is critical to explicitly declare *all* prerequisite API calls necessary to prepare the test context within the `dependencies` array, with special attention to authentication requirements.\n* Dependencies represent logical requirements for the scenario and may require strict execution order, especially for authentication flows.\n* When there *is* a required sequence, such as creating a user before creating a resource tied to that user, you **must** clearly indicate this order in both the scenario's `draft` description and in the `purpose` explanation of each dependency.\n* Authentication sequences are particularly order-sensitive and must be explicitly described with proper role establishment flow.\n* This explicit approach prevents using placeholder or fake data (like dummy UUIDs) and instead ensures that all data setup is conducted via real API calls, increasing test reliability and maintainability.\n* Providing clear and detailed `draft` text describing the full user workflow, authentication context, and error expectations helps downstream agents or developers generate complete and realistic test implementations.\n\nBy following these guidelines, generated test scenarios will be comprehensive, accurate, and fully grounded in the actual API ecosystem and business logic with proper authentication context.\n\n## 8. Final Checklist\n\n### 8.1. Essential Element Verification\n\n* [ ] Are all included endpoints covered with appropriate scenarios?\n* [ ] Do scenarios reflect realistic business workflows and user journeys?\n* [ ] Are function names descriptive and follow the business feature-centric naming convention?\n* [ ] Are all necessary dependencies identified and properly ordered?\n* [ ] Do dependency purposes clearly explain why each prerequisite is needed?\n* [ ] Are both success and failure scenarios included for complex operations?\n* [ ] Do scenarios test relevant business rules and validation constraints?\n* [ ] Are authentication requirements properly analyzed from both Operations array (`authorizationRole`) and \"Included in Test Plan\" section?\n\n### 8.2. Quality Element Verification\n\n* [ ] Are scenario descriptions detailed enough for developers to implement?\n* [ ] Do scenarios represent authentic user needs and workflows?\n* [ ] Is the business context clearly explained for each scenario?\n* [ ] Are error scenarios realistic and cover important failure conditions?\n* [ ] Do multi-step scenarios include all necessary intermediate steps?\n* [ ] Are scenarios grouped logically by endpoint and functionality?\n* [ ] Are authentication flows properly detailed with role context?\n\n### 8.3. Structural Verification\n\n* [ ] Does the output follow the correct IAutoBeTestScenarioApplication.IProps structure?\n* [ ] Are all endpoint objects properly formatted with method and path?\n* [ ] Do all scenarios include required fields (draft, functionName, dependencies)?\n* [ ] Are dependency objects complete with endpoint and purpose information?\n* [ ] Is each endpoint method/path combination unique in the scenario groups?\n\n### 8.4. Authentication Verification\n\n* [ ] For endpoints with authorizationRole: Are appropriate \"join\" operations included in dependencies for single-role scenarios?\n* [ ] For multi-role scenarios: Are \"join\" operations used for each new user creation and context switching?\n* [ ] For returning to previous users: Is \"login\" used only when switching back to previously created users?\n* [ ] For public endpoints: Is authentication skipped unless scenario logically requires it?\n* [ ] Are authentication sequences properly described in dependency purposes with role establishment details?\n* [ ] Is authentication context established before testing protected endpoints with proper flow order?\n* [ ] Have you referenced the \"Included in Test Plan\" section to identify available authentication APIs for each endpoint?\n* [ ] Have you checked the `authorizationRole` field in the Operations array to understand role requirements?" /* AutoBeSystemPromptConstant.TEST_SCENARIO */,
+        },
+        {
+            id: (0, uuid_1.v4)(),
+            created_at: new Date().toISOString(),
+            type: "systemMessage",
+            text: [
+                "# Operations",
+                "",
+                "Below are the full operations. Please refer to this.",
+                "Your role is to draft all test cases for each given Operation.",
+                "It is also permissible to write multiple test codes on a single endpoint.",
+                "However, rather than meaningless tests, business logic tests should be written and an E2E test situation should be assumed.",
+                "",
+                "Please carefully analyze each operation to identify all dependencies required for testing.",
+                "For example, if you want to test liking and then deleting a post,",
+                "you might think to test post creation, liking, and unlike operations.",
+                "However, even if not explicitly mentioned, user registration or login are essential prerequisites.",
+                "Pay close attention to IDs and related values in the API,",
+                "and ensure you identify all dependencies between endpoints.",
+                "",
+                "```json",
+                JSON.stringify(entire.map((el) => (Object.assign(Object.assign({}, el), { specification: undefined })))),
+                "```",
+            ].join("\n"),
+        },
+        {
+            id: (0, uuid_1.v4)(),
+            created_at: new Date().toISOString(),
+            type: "systemMessage",
+            text: [
+                "# Included in Test Plan",
+                "",
+                "Below are the endpoints that have been included in the test plan.",
+                "Each endpoint shows its authentication requirements and related authentication APIs.",
+                "When testing endpoints that require authentication, ensure you include the corresponding join/login operations in your test scenario to establish proper authentication context.",
+                "",
+                include
+                    .map((el, i) => {
+                    const roles = Array.from(authorizationRoles.values()).filter((role) => role.name === el.authorizationRole);
+                    return [
+                        `## ${i + 1}. ${el.method.toUpperCase()} ${el.path}`,
+                        "",
+                        "Related Authentication APIs:",
+                        "",
+                        roles.length > 0
+                            ? roles.map((role) => {
+                                var _a, _b, _c, _d;
+                                return [
+                                    `- ${(_a = role.join) === null || _a === void 0 ? void 0 : _a.method.toUpperCase()}: ${(_b = role.join) === null || _b === void 0 ? void 0 : _b.path}`,
+                                    `- ${(_c = role.login) === null || _c === void 0 ? void 0 : _c.method.toUpperCase()}: ${(_d = role.login) === null || _d === void 0 ? void 0 : _d.path}`,
+                                ].join("\n");
+                            })
+                            : "- None",
+                    ];
+                })
+                    .join("\n"),
+                "",
+                "# Excluded from Test Plan",
+                "",
+                "These are the endpoints that have already been used in test codes generated as part of a plan group.",
+                "These endpoints do not need to be tested again.",
+                "However, it is allowed to reference or depend on these endpoints when writing test codes for other purposes.",
+                exclude
+                    .map((el) => `- ${el.method.toUpperCase()}: ${el.path}`)
+                    .join("\n"),
+            ].join("\n"),
+        },
+    ];
+};
+exports.transformTestScenarioHistories = transformTestScenarioHistories;
+//# sourceMappingURL=transformTestScenarioHistories.js.map

package/lib/agent/src/orchestrate/test/histories/transformTestScenarioHistories.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"transformTestScenarioHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/test/histories/transformTestScenarioHistories.ts"],"names":[],"mappings":";;;AAEA,yCAAwC;AACxC,+BAA0B;AAMnB,MAAM,8BAA8B,GAAG,CAC5C,KAAkB,EAClB,MAAkC,EAClC,OAAmC,EACnC,OAA4D,EAG5D,EAAE;;IACF,MAAM,cAAc,GAClB,MAAA,MAAA,KAAK,CAAC,SAAS,0CAAE,cAAc,mCAAI,EAAE,CAAC;IAExC,MAAM,kBAAkB,GACtB,IAAI,GAAG,EAAE,CAAC;IAEZ,KAAK,MAAM,aAAa,IAAI,cAAc,EAAE,CAAC;QAC3C,KAAK,MAAM,EAAE,IAAI,aAAa,CAAC,UAAU,EAAE,CAAC;YAC1C,IAAI,EAAE,CAAC,iBAAiB,KAAK,IAAI;gBAAE,SAAS;YAC5C,MAAM,KAAK,GAAyC,eAAO,CAAC,IAAI,CAC9D,kBAAkB,EAClB,aAAa,CAAC,IAAI,EAClB,GAAG,EAAE,CAAC,CAAC;gBACL,IAAI,EAAE,aAAa,CAAC,IAAI;gBACxB,IAAI,EAAE,IAAI;gBACV,KAAK,EAAE,IAAI;aACZ,CAAC,CACH,CAAC;YACF,IAAI,EAAE,CAAC,iBAAiB,KAAK,MAAM;gBAAE,KAAK,CAAC,IAAI,GAAG,EAAE,CAAC;iBAChD,IAAI,EAAE,CAAC,iBAAiB,KAAK,OAAO;gBAAE,KAAK,CAAC,KAAK,GAAG,EAAE,CAAC;QAC9D,CAAC;IACH,CAAC;IAED,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,o/1BAA0C;SACD;QAC/C;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE;gBACJ,cAAc;gBACd,EAAE;gBACF,sDAAsD;gBACtD,gEAAgE;gBAChE,2EAA2E;gBAC3E,6HAA6H;gBAC7H,EAAE;gBACF,4FAA4F;gBAC5F,mEAAmE;gBACnE,uEAAuE;gBACvE,oGAAoG;gBACpG,2DAA2D;gBAC3D,6DAA6D;gBAC7D,EAAE;gBACF,SAAS;gBACT,IAAI,CAAC,SAAS,CACZ,MAAM,CAAC,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,iCACd,EAAE,KACL,aAAa,EAAE,SAAS,IACxB,CAAC,CACJ;gBACD,KAAK;aACN,CAAC,IAAI,CAAC,IAAI,CAAC;SACiC;QAC/C;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE;gBACJ,yBAAyB;gBACzB,EAAE;gBACF,mEAAmE;gBACnE,sFAAsF;gBACtF,kLAAkL;gBAClL,EAAE;gBACF,OAAO;qBACJ,GAAG,CAAC,CAAC,EAAE,EAAE,CAAC,EAAE,EAAE;oBACb,MAAM,KAAK,GAAG,KAAK,CAAC,IAAI,CAAC,kBAAkB,CAAC,MAAM,EAAE,CAAC,CAAC,MAAM,CAC1D,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,IAAI,KAAK,EAAE,CAAC,iBAAiB,CAC7C,CAAC;oBACF,OAAO;wBACL,MAAM,CAAC,GAAG,CAAC,KAAK,EAAE,CAAC,MAAM,CAAC,WAAW,EAAE,IAAI,EAAE,CAAC,IAAI,EAAE;wBACpD,EAAE;wBACF,8BAA8B;wBAC9B,EAAE;wBACF,KAAK,CAAC,MAAM,GAAG,CAAC;4BACd,CAAC,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE;;gCACjB,OAAO;oCACL,KAAK,MAAA,IAAI,CAAC,IAAI,0CAAE,MAAM,CAAC,WAAW,EAAE,KAAK,MAAA,IAAI,CAAC,IAAI,0CAAE,IAAI,EAAE;oCAC1D,KAAK,MAAA,IAAI,CAAC,KAAK,0CAAE,MAAM,CAAC,WAAW,EAAE,KAAK,MAAA,IAAI,CAAC,KAAK,0CAAE,IAAI,EAAE;iCAC7D,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;4BACf,CAAC,CAAC;4BACJ,CAAC,CAAC,QAAQ;qBACb,CAAC;gBACJ,CAAC,CAAC;qBACD,IAAI,CAAC,IAAI,CAAC;gBACb,EAAE;gBACF,2BAA2B;gBAC3B,EAAE;gBACF,sGAAsG;gBACtG,iDAAiD;gBACjD,8GAA8G;gBAC9G,OAAO;qBACJ,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,KAAK,EAAE,CAAC,MAAM,CAAC,WAAW,EAAE,KAAK,EAAE,CAAC,IAAI,EAAE,CAAC;qBACvD,IAAI,CAAC,IAAI,CAAC;aACd,CAAC,IAAI,CAAC,IAAI,CAAC;SACiC;KAChD,CAAC;AACJ,CAAC,CAAC;AA/GW,QAAA,8BAA8B,kCA+GzC"}

package/lib/{orchestrate/test → agent/src/orchestrate/test/histories}/transformTestWriteHistories.d.ts

@@ -1,6 +1,6 @@
 import { IAgenticaHistoryJson } from "@agentica/core";
 import { AutoBeTestScenario } from "@autobe/interface";
-import { IAutoBeTestScenarioArtifacts } from "./structures/IAutoBeTestScenarioArtifacts";
+import { IAutoBeTestScenarioArtifacts } from "../structures/IAutoBeTestScenarioArtifacts";
 export declare function transformTestWriteHistories(scenario: AutoBeTestScenario, artifacts: IAutoBeTestScenarioArtifacts): Array<IAgenticaHistoryJson.ISystemMessage>;
 export declare namespace transformTestWriteHistories {
     function structures(artifacts: IAutoBeTestScenarioArtifacts): string;