@autobe/agent 0.17.1 → 0.18.0

package/lib/agent/src/orchestrate/realize/structures/IAutoBeRealizeWriteApplication.d.ts

@@ -0,0 +1,276 @@
+export interface IAutoBeRealizeWriteApplication {
+    coding: (next: IAutoBeRealizeWriteApplication.IProps) => void;
+}
+export declare namespace IAutoBeRealizeWriteApplication {
+    interface IProps {
+        /**
+         * Step 1.
+         *
+         * 🧠 Provider Function Implementation Plan
+         *
+         * This field outlines the strategic plan for implementing the provider
+         * 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:
+         *
+         * 📋 STEP 1 - PRISMA SCHEMA VERIFICATION (MOST CRITICAL):
+         *
+         * - 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`
+         *
+         * 📋 STEP 2 - FIELD INVENTORY:
+         *
+         * - List ONLY fields confirmed to exist in schema
+         * - Example: "Verified fields in user model: id (String), email (String),
+         *   created_at (DateTime), updated_at (DateTime)"
+         * - Example: "Fields that DO NOT exist: deleted_at, is_active, created_by"
+         *
+         * 📋 STEP 3 - FIELD ACCESS STRATEGY:
+         *
+         * - Plan which verified fields will be used in select, update, create
+         *   operations
+         * - For complex operations with type errors, plan to use separate queries
+         *   instead of nested operations
+         *
+         * 📋 STEP 4 - TYPE COMPATIBILITY:
+         *
+         * - Plan DateTime to ISO string conversions using toISOStringSafe()
+         * - Plan handling of nullable vs required fields
+         *
+         * 📋 STEP 5 - IMPLEMENTATION APPROACH:
+         *
+         * - 🧩 Required business entities (e.g., users, posts, logs) and their
+         *   relationships
+         * - 🛠 Operations needed to fulfill the business scenario (e.g., fetch,
+         *   create, update) using ONLY verified fields
+         * - 🔄 Data dependencies between steps (e.g., use userId to fetch related
+         *   data)
+         * - ✅ Validation points (based on business rules, not field presence)
+         * - 🚧 Error and edge cases that must be handled explicitly (e.g., missing
+         *   records)
+         * - 🏗 Structure: always a single `async function`, using only `parameters`
+         *   and `body`
+         *
+         * ⚠️ Important Constraints:
+         *
+         * - Do NOT perform input validation — assume `parameters` and `body` are
+         *   already valid
+         * - Use `typia.random<T>()` with an explanatory comment if logic can't be
+         *   implemented
+         * - Never use `any` or make assumptions without sufficient context
+         * - Use only allowed imports — DTOs and Prisma types
+         * - Use `MyGlobal.prisma` for DB access and respect Prisma typing rules
+         *
+         * ⚠️ TypeScript-specific considerations:
+         *
+         * - Do **not** use native `Date` objects directly; always convert all dates
+         *   using `toISOStringSafe()` and brand as `string &
+         *   tags.Format<'date-time'>`. This rule applies throughout all phases.
+         * - Prefer `satisfies` for DTO conformance instead of unsafe `as` casts
+         * - Avoid weak typing such as `any`, `as any`, or `satisfies any`
+         * - Use branded types (e.g., `tags.Format<'uuid'>`) and literal unions where
+         *   applicable
+         *
+         * ✅ Example Structure:
+         *
+         * ```ts
+         * export async function doSomething(
+         *   user: { id: string & tags.Format<"uuid">; type: string },
+         *   parameters: IParams,
+         *   body: IBody
+         * ): Promise<IReturn> {
+         *   const { id } = parameters;
+         *   const { name } = body;
+         *   const user = await MyGlobal.prisma.users.findFirst({ where: { id } });
+         *   if (!user) throw new Error("User not found");
+         *   ...
+         *   return result;
+         * }
+         * ```
+         *
+         * 🔍 Feasibility Analysis Requirement:
+         *
+         * - Before generating any code, the agent **must analyze** whether the
+         *   requested implementation is **feasible based on the given Prisma schema
+         *   and DTO types**.
+         * - If required fields or relationships are **missing or incompatible**, the
+         *   plan should explicitly state that the implementation is **not
+         *   possible** with the current schema/DTO, and no code should be generated
+         *   in later stages.
+         * - In such cases, only a detailed **comment in the `implementationCode`**
+         *   should be returned explaining why the logic cannot be implemented.
+         *
+         * 🔥 Error Handling Plan:
+         *
+         * If an error is expected or encountered during implementation:
+         *
+         * - Clearly document the error message(s) and TypeScript error codes.
+         * - Analyze the root cause (e.g., type mismatch, missing field, nullability
+         *   issue).
+         * - Define concrete steps to resolve the issue, such as:
+         *
+         *   - Adjusting type declarations or using Prisma-generated input types.
+         *   - Using `?? undefined` to normalize nullable fields.
+         *   - Applying correct relation handling (e.g., `connect` instead of direct
+         *       foreign key assignment).
+         *   - Ensuring all date fields use `.toISOString()` and proper branding.
+         * - Include fallback or workaround plans if a direct fix is complex.
+         * - If no error is present, simply omit this section.
+         *
+         * This plan ensures the function will:
+         *
+         * - Respect the global architecture and coding conventions
+         * - Be safe, predictable, and aligned with upstream logic
+         */
+        plan: string;
+        /**
+         * Step 2.
+         *
+         * The Prisma schema string that will be used to validate the implementation
+         * logic in this file.
+         *
+         * You must **explicitly specify only the relevant models and fields** from
+         * your full schema that are used in this implementation. This ensures that
+         * your logic is aligned with the expected database structure without
+         * accidentally introducing unrelated fields or models.
+         *
+         * ⚠️ Important: The value of this field must be a valid Prisma schema
+         * string containing only the models used in this code — not the entire
+         * schema.
+         *
+         * This acts as a safeguard against:
+         *
+         * - Forgetting required fields used in this implementation
+         * - Including fields or models that are not actually used
+         */
+        prisma_schemas: string;
+        /**
+         * Step 3.
+         *
+         * 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.
+         *
+         * - The function signature must correctly include `user`, `parameters`, and
+         *   `body` arguments.
+         * - Design the main flow of business logic, such as DB fetches and early
+         *   returns based on conditions.
+         * - Mark any incomplete or missing parts clearly with placeholders (e.g.,
+         *   comments or temporary values).
+         *
+         * ⚠️ 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.
+         *
+         * ✅ Requirements:
+         *
+         * - Avoid using the `any` type at all costs to ensure type safety.
+         * - NEVER declare variables with `: Date` type
+         * - ALWAYS use `string & tags.Format<'date-time'>` for date values
+         * - Use `toISOStringSafe(new Date())` for current timestamps
+         * - Maintain a single-function structure; avoid using classes.
+         */
+        draft_without_date_type: string;
+        /**
+         * Step 4.
+         *
+         * A refined version of the draft with improved completeness.
+         *
+         * - Replace placeholder logic with real DTO-conformant operations.
+         * - Add error handling (`throw new Error(...)`) where necessary.
+         * - Begin resolving structural or type mismatches.
+         *
+         * ✅ Requirements:
+         *
+         * - Use `satisfies` to ensure DTO conformity.
+         * - Avoid unsafe `as` casts unless only for branding or literal narrowing.
+         * - Use `toISOStringSafe()` for all date conversions (NOT `.toISOString()`).
+         * - Ensure all object keys strictly conform to the expected type definitions.
+         */
+        review: string;
+        /**
+         * 🛠 Phase 4-2: With compiler feedback (optional)
+         *
+         * A correction pass that applies fixes for compile-time errors that arose
+         * during the review stage (if any).
+         *
+         * ✅ Must:
+         *
+         * - Only include this field if TypeScript errors are detected in the Review
+         *   phase.
+         * - Resolve all TypeScript errors without using `as any`.
+         * - Provide safe brand casting only if required (e.g., `as string &
+         *   tags.Format<'uuid'>`).
+         * - If no TypeScript errors exist, this field MUST contain the text: "No
+         *   TypeScript errors detected - skipping this phase"
+         */
+        withCompilerFeedback: string;
+        /**
+         * Step 5.
+         *
+         * The complete and fully correct TypeScript function implementation.
+         *
+         * - Passes strict type checking without errors.
+         * - Uses only safe branding or literal type assertions.
+         * - Converts all date values properly using `toISOStringSafe()`.
+         * - Follows DTO structures using `satisfies`.
+         * - Avoids any weak typing such as `any`, `as any`, or `satisfies any`.
+         * - Uses only allowed imports (e.g., from `../api/structures` and
+         *   `MyGlobal.prisma`).
+         * - NEVER creates intermediate variables for Prisma operations.
+         *
+         * ⚠️ Fallback Behavior:
+         *
+         * - If the `plan` phase explicitly determines that the requested logic is
+         *   **not feasible** due to mismatches or limitations in the provided
+         *   Prisma schema and DTO types:
+         *
+         *   - The implementation must still return a syntactically valid function.
+         *   - In such cases, return mock data using `typia.random<T>()` wrapped in the
+         *       correct structure, along with a comment explaining the limitation.
+         *
+         *   Example fallback:
+         *
+         * ```ts
+         *   // ⚠️ Cannot implement logic due to missing relation between A and B
+         *   export async function someFunction(...) {
+         *     return typia.random<IReturn>(); // mocked output
+         *   }
+         * ```
+         *
+         * ⚠️ Prohibited Practices:
+         *
+         * - Do NOT add or modify import statements manually. Imports are handled
+         *   automatically by the system.
+         * - Do NOT use `any`, `as any`, or `satisfies any` to bypass type checking.
+         * - Do NOT assign native `Date` objects directly; always convert them using
+         *   `toISOStringSafe()`.
+         * - Do NOT use unsafe type assertions except for safe branding or literal
+         *   narrowing.
+         * - Do NOT write code outside the single async function structure (e.g., no
+         *   classes or multiple functions).
+         * - Do NOT perform any input validation — assume all inputs are already
+         *   validated.
+         * - Do NOT use dynamic import expressions (`import()`); all imports must be
+         *   static.
+         * - Do NOT use Prisma-generated input types; always use types from
+         *   `../api/structures`.
+         * - Do NOT use `Object.prototype.hasOwnProperty.call()` for field checks.
+         * - Do NOT escape newlines or quotes in the implementation string (e.g., no
+         *   `\\n` or `\"`); use a properly formatted template literal with actual
+         *   line breaks instead.
+         */
+        implementationCode: string;
+    }
+}

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

@@ -71,6 +71,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,0DAuHC;AAvHD,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,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,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.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,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 → 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,3 @@
+import { IAgenticaHistoryJson } from "@agentica/core";
+import { AutoBeOpenApi } from "@autobe/interface";
+export declare const transformTestScenarioHistories: (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,56 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.transformTestScenarioHistories = void 0;
+const uuid_1 = require("uuid");
+const transformTestScenarioHistories = (entire, include, exclude) => [
+    {
+        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_` prefix (format: `test_{action}_{resource}_{context}`)\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\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 and path\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\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.\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\n## 2.3. Authentication Rules\n\n**CRITICAL**: Each endpoint in the Include List shows its authorizationRole value. Follow these rules:\n\n* **If authorizationRole exists (not null)**: MUST include user registration \u2192 login APIs before testing the endpoint\n* **If authorizationRole is null**: No authentication required unless the scenario logically needs it\n* **Authentication Sequence**: When authentication is needed, always follow: registration \u2192 login \u2192 target API\n\nExample:\n- `POST /users/register` \u2192 No authentication required\n- `POST /admin/products (Role: admin)` \u2192 Must include admin registration + login\n- `GET /my/orders (Role: user)` \u2192 Must include user registration + login\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. 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 must be done first to ensure proper authorization.\"\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 must be done after seller creation.\"\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\n* **Logical Ordering**: Ensure dependencies are listed in the correct execution order if step-by-step execution is required\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. If execution order is relevant, describe it explicitly 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 for the test scenario\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**: 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\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* **Step-by-Step Process**: Detailed description of the testing process, including all necessary steps\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 user-centric naming convention:\n\n* **Prefix**: Must start with `test_`\n* **User Action**: Primary action the user is performing (create, get, update, delete, search, etc.)\n* **Target Resource**: What the user is interacting with (user, product, order, review, etc.)\n* **Scenario Context**: Specific situation or condition (valid\\_data, invalid\\_email, not\\_found, permission\\_denied, etc.)\n\n**Examples:**\n\n* `test_create_product_with_valid_data`\n* `test_update_product_price_without_permission`\n* `test_search_products_with_empty_results`\n* `test_delete_product_that_does_not_exist`\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\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\n### 5.5. Multi-Scenario Planning\n\nFor complex endpoints, generate multiple scenarios covering:\n\n* **Happy Path**: Successful execution with valid data\n* **Validation Errors**: Various types of input validation failures\n* **Permission Errors**: Unauthorized access attempts\n* **Resource State Errors**: Operations on resources in invalid states\n* **Business Rule Violations**: Attempts to violate domain-specific business rules\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.**\n* **Execution order, if required, should be explained in the `purpose`.**\n\nExample:\n\n```yaml\n  dependencies:\n    - endpoint: { method: \"post\", path: \"/posts\" }\n      functionName: \"test_api_post_creation_valid_data\"\n      purpose: \"Create a post and extract postId for use in voting scenario\"\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\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\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. 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. 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 ensure proper authorization.\"\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.\"\n    }\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.\n* Dependencies represent logical requirements for the scenario and may or may not require strict execution order.\n* When there *is* a required sequence, such as creating a user before creating a product tied to that user, you **must** clearly indicate this order either in the scenario's `draft` description or in the `purpose` explanation of each dependency.\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 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.\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 user-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\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\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 registration \u2192 login dependencies included?\n* [ ] For public endpoints: Is authentication skipped unless scenario requires it?\n* [ ] Are authentication sequences properly ordered in dependencies?" /* 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 and 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",
+            include
+                .map((el) => `- ${el.method.toUpperCase()}: ${el.path} ${el.authorizationRole ? `(Role: ${el.authorizationRole})` : ""}`)
+                .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,+BAA0B;AAInB,MAAM,8BAA8B,GAAG,CAC5C,MAAkC,EAClC,OAAmC,EACnC,OAA4D,EAG5D,EAAE,CAAC;IACH;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE,eAAe;QACrB,IAAI,u4kBAA0C;KACD;IAC/C;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE,eAAe;QACrB,IAAI,EAAE;YACJ,cAAc;YACd,sDAAsD;YACtD,gEAAgE;YAChE,2EAA2E;YAC3E,6HAA6H;YAC7H,EAAE;YACF,4FAA4F;YAC5F,mEAAmE;YACnE,uEAAuE;YACvE,qGAAqG;YACrG,2DAA2D;YAC3D,6DAA6D;YAC7D,EAAE;YACF,SAAS;YACT,IAAI,CAAC,SAAS,CACZ,MAAM,CAAC,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,iCACd,EAAE,KACL,aAAa,EAAE,SAAS,IACxB,CAAC,CACJ;YACD,KAAK;SACN,CAAC,IAAI,CAAC,IAAI,CAAC;KACiC;IAC/C;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE,eAAe;QACrB,IAAI,EAAE;YACJ,yBAAyB;YACzB,OAAO;iBACJ,GAAG,CACF,CAAC,EAAE,EAAE,EAAE,CACL,KAAK,EAAE,CAAC,MAAM,CAAC,WAAW,EAAE,KAAK,EAAE,CAAC,IAAI,IAAI,EAAE,CAAC,iBAAiB,CAAC,CAAC,CAAC,UAAU,EAAE,CAAC,iBAAiB,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAC9G;iBACA,IAAI,CAAC,IAAI,CAAC;YACb,EAAE;YACF,2BAA2B;YAC3B,sGAAsG;YACtG,iDAAiD;YACjD,8GAA8G;YAC9G,OAAO;iBACJ,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,KAAK,EAAE,CAAC,MAAM,CAAC,WAAW,EAAE,KAAK,EAAE,CAAC,IAAI,EAAE,CAAC;iBACvD,IAAI,CAAC,IAAI,CAAC;SACd,CAAC,IAAI,CAAC,IAAI,CAAC;KACiC;CAChD,CAAC;AA/DW,QAAA,8BAA8B,kCA+DzC"}

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;